<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 1:08 PM, Brent Putman wrote:<br>
</div>
<blockquote cite="mid:55AE7CA7.70601@georgetown.edu" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
<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>
</blockquote>
<br>
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:<br>
<br>
<tt> try {</tt><tt><br>
</tt><tt> final InputStream stream =
super.getInputStream();</tt><tt><br>
</tt><tt> <font color="#ff0000">return
saveAndClone(stream);</font></tt><tt><br>
</tt><tt> } catch (IOException ex) {</tt><tt><br>
</tt><tt> log.warn("{} HTTP resource was inaccessible for
getInputStream(), trying backing file.", </tt><tt><br>
</tt><tt> getDescription());</tt><tt> </tt><br>
<br>
<br>
So either:<br>
1) the super.getInputStream() is throwing b/c of issues with the
HttpClient call (what I assumed before)<br>
<br>
OR<br>
<br>
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.<br>
<br>
I want to see the DEBUG output, but I'm suspecting #2.<br>
</body>
</html>