<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 8/16/17 2:37 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DFE5A948-18C0-4918-9083-F15B518A61FC@osu.edu">
<pre wrap="">On 8/16/17, 2:09 PM, "users on behalf of <a class="moz-txt-link-abbreviated" href="mailto:shibboleth655@lewenberg.com">shibboleth655@lewenberg.com</a>" <a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@shibboleth.netonbehalfofshibboleth655@lewenberg.com"><users-bounces@shibboleth.net on behalf of shibboleth655@lewenberg.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">But on the problematic server, after the error message about not being
able to download the metadata file, no more messages, good or bad, in
the process log about that metadata file.
</pre>
</blockquote>
<pre wrap="">
If there are bugs crashing the reload thread, nobody has reported them or observed them in a long time, so there's really nothing much to be said. Without a logged exception, which I thought we caught now, I don't see that there's any way to learn anything. If we're not catching Throwable, then I suppose the answer is that it must have crashed and it seems to me we should be catching Throwable, at least to log it.</pre>
</blockquote>
<br>
Yes, we do catch Throwable covering the whole refresh(), and have
for a long time now (several years). That was to deal with some
(very rare) events throwing java.lang.Error which is not a subtype
of java.lang.Exception that we used to catch, and so no next refresh
was being scheduled.<br>
<br>
So I also don't have an explanation for no logging in 3.3.1, nor any
intuition about what might be going on. If there is something
environmental in the servlet container that's literally causing the
Timer thread to just silently die or get hung, etc, then that could
be an explanation. But I've never heard of that happening, nor do I
know if it's even possible (silently, I mean). And any remediation
would likely be outside of anything we can control. <br>
<br>
Looks like the OP's logging here is just on INFO? (just inferring
from what was posted) I'd suggest turning it up to DEBUG for
package org.opensaml.saml.metadata.resolver. It is possible that
there is some non-error code path that does not log anything on INFO
or WARN. Getting some DEBUG will at least confirm whether or not
*something* is happening at the expected reload times.<br>
<br>
<blockquote type="cite"
cite="mid:DFE5A948-18C0-4918-9083-F15B518A61FC@osu.edu">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Note that the source metadata file itself has not changed since January 2017.
</pre>
</blockquote>
<pre wrap="">
If it hasn't changed, I don't understand why any of them are updating the file unless the web server isn't handling the conditional requests it should be receiving. It should never update on the IdP end at all outside of restarts.</pre>
</blockquote>
<br>
<br>
This is probably not involved in the OP's issue (in fact it should
result in *more* logging), but for me the conditional GET for
<a class="moz-txt-link-freetext" href="https://idp.stanford.edu/Stanford-idps.xml">https://idp.stanford.edu/Stanford-idps.xml</a> is not working, according
to FF Live Headers. An initial non-conditional GET sends back
Last-Modified and Etag. A followup conditional GET with
If-Modified-Since and If-None-Match results in a 200 with
'Content-Length: 21498', not the expected 304 Not Modified. Someone
at Stanford might want to look into that. <br>
<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:DFE5A948-18C0-4918-9083-F15B518A61FC@osu.edu">
</blockquote>
<br>
</body>
</html>