<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 7/21/15 12:51 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:147FD267-DC69-43CF-8CB2-CC7716E840B1@osu.edu"
type="cite"><br>
<pre wrap="">
Ok, admittedly I interpreted "no backup file yet" as equivalent to the file cache not being populated either, which aren't necessarily equivalent. So that is the first question to ask, and one can always flush that directory.
</pre>
</blockquote>
<br>
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).<br>
<br>
What would be very informative is to see:<br>
<br>
1) the DEBUG output from
net.shibboleth.ext.spring.resource.HTTPResource. That will report
what the caching status of the file as reported by HttpClient.<br>
<br>
2) the ERROR level output reporting exactly what HTTP status code
was effectively returned from the client call. My previous testing
and understanding what that if the HttpClient served the response
from cache, then you get back a 200, but perhaps that's not always
the case. The superclass getInputStream() has the code block:<br>
<br>
<tt> if (httpStatusCode != HttpStatus.SC_OK) {</tt><tt><br>
</tt><tt> String errMsg =</tt><tt><br>
</tt><tt> "Non-ok status code " + httpStatusCode
+ " returned from remote resource " + resourceURL;</tt><tt><br>
</tt><tt> log.error(errMsg);</tt><tt><br>
</tt><tt> throw new IOException(errMsg);</tt><tt><br>
</tt><tt> }</tt><br>
<br>
I'd like to confirm that that is what's happening to throw the
IOException caught by the FileBacked- subclass, and what the exact
code is. Perhaps we are misusing the HttpClient there, i.e. maybe
codes other than SC_OK should be treated as success. Just guessing.
Or maybe there really is a bug in HttpClient somewhere.<br>
<br>
Also interesting would be DEBUG output from org.apache.http.
(Warning: that will be a lot, since org.apache.http.wire does a wire
level dump of all the traffic).<br>
<br>
Another thing to look at might be the max cache entry size: We have
for the FileCachingHttpClient default of:<br>
<br>
<tt>p:maxCacheEntrySize="%{idp.httpclient.filecaching.maxCacheEntrySize:10485760}<br>
<br>
</tt>so 10MB. Could the resource being fetched here be bigger than
that? I have thought that if the resource is bigger, it simply isn't
cached, but perhaps it's more complicated and/or there is a bug
around that (ours or theirs).<br>
<br>
Finally, might be informative to see if instead switching to the
shibboleth.MemoryCachingHttpClient resolves the issue. Might hint
where the problem is.<br>
<br>
</body>
</html>