Configuring a file-backed HTTP resource for attribute filters

[Wessel, Keith]

#2 would make more sense, too, since it's the creation of the backing file, not subsequent updates, that cause the error.

I again apologize for throwing you off with mis-information about the 304 response code.

I'll get you logs shortly. If you still want it, I just sent the attribute filter file URL to Scott off-list.

Keith


From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Brent Putman
Sent: Tuesday, July 21, 2015 4:12 PM
To: users at shibboleth.net
Subject: Re: Configuring a file-backed HTTP resource for attribute filters


On 7/21/15 1:08 PM, Brent Putman wrote:


Looking at the code, the backup file referenced is definitely ours.  The root issue happens before that, something is going wrong with the FileBacked- class call to super.getInputStream() (the regular HttpResource).

Looking at the code again more closely, this might be a mis-diagnosis.  The actual code there before line 117 where the WARN is logged is:

        try {
            final InputStream stream = super.getInputStream();
            return saveAndClone(stream);
        } catch (IOException ex) {
            log.warn("{} HTTP resource was inaccessible for getInputStream(), trying backing file.",
                    getDescription());


So either:
1) the super.getInputStream() is throwing b/c of issues with the HttpClient call (what I assumed before)

OR

2) (what I didn't see before)  the saveAndClone(..) call to create the backup file from the HTTP response is throwing.  The log output is misleading by itself, because it then tries *again* to load from the backing file.  I didn't get that before.

I want to see the DEBUG output, but I'm suspecting #2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150721/e0b088cf/attachment.html>