Shibboleth IdP fails to download metadata then never tries again

[Brent Putman]

On 8/16/17 2:37 PM, Cantor, Scott wrote:
> On 8/16/17, 2:09 PM, "users on behalf of shibboleth655 at lewenberg.com" <users-bounces at shibboleth.net on behalf of shibboleth655 at lewenberg.com> wrote:
>
>> 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.
> 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.

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.

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. 

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.

>
>> Note that the source metadata file itself has not changed since January 2017.
> 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.


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
https://idp.stanford.edu/Stanford-idps.xml 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. 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170816/8d0f07ad/attachment.html>