Shib IdP 2.4 metadata refresh bug?

[Brent Putman]

On 4/20/15 12:43 PM, Cantor, Scott wrote:
> On 4/20/15, 12:06 PM, "Michael A Grady" <mgrady at unicon.net> wrote:
>
>> I've been trying to help someone running IdP 2.4
> 2.4.what? If it's not the latest, that's step 1.

Yes.  If it's anything less than the latest 2.4.4, then you get into the
issues with the shared Timer and HttpClient timeouts.  Anything less
than 2.4.1 you also have issues with certain types of exceptions/errors
not being caught (below).

>
> I doubt it's related, it's just failing the InCommon update task and eventually it runs the other one (they're 45 minutes apart aren't they?)

Yeah, I don't see any relation either, at least not from the logs that
were posted.


>
> I'm starting to believe given the number of people who have suddenly started having issues that the old and now dead HttpClient library used by V2 has a regression that ended up creating exceptions that used to be handled more appropriately. 

Well, maybe, but we have literally been on the exact same version of
commons-httpclient (v3.1) for the entire life of the 2.x IdP.  B/c it's
dead ... so there was nothing to upgrade.    So there haven't been any
changes in that library that would have caused anything to change in the
IdP behavior, as far as I can see.



> Either way, the latest patches reduced the potential overlap between refresh tasks so that the problems are more confined, but it's still a single threaded timer with not much chance of recovering from issues. I don't know what the logging looks like. V3 has a more aggressive catch clause for Throwable now to log problems, don't know that V2 does.


Per IDP-624 our initial stab at fixing this back in 11/2013 was to
change the refresh() logic to use a catch Throwable instead of
Exception.  That was included in IdP 2.4.1. So nothing being thrown by
the commons-httpclient or anything else called during the refresh()
should now result in the next refresh not getting scheduled, at least as
far as we know.  We also have some DEBUG logging around that so we
should at least know that that's happening.  It will read "Error
occurred while attempting to refresh metadata from..." and include the
Throwable stack trace that was thrown.  AFAIK, no one has yet reported
actually seeing this happen in the wild.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150420/fd3e53d1/attachment-0001.html>