<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 4/20/15 12:43 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:A116E45D-A78F-43F2-B4BA-80D163E4A68B@osu.edu"
type="cite">
<pre wrap="">On 4/20/15, 12:06 PM, "Michael A Grady" <a class="moz-txt-link-rfc2396E" href="mailto:mgrady@unicon.net"><mgrady@unicon.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I've been trying to help someone running IdP 2.4
</pre>
</blockquote>
<pre wrap="">
2.4.what? If it's not the latest, that's step 1.</pre>
</blockquote>
<br>
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).<br>
<br>
<blockquote cite="mid:A116E45D-A78F-43F2-B4BA-80D163E4A68B@osu.edu"
type="cite"><br>
<pre wrap="">
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?)</pre>
</blockquote>
<br>
Yeah, I don't see any relation either, at least not from the logs
that were posted.<br>
<br>
<br>
<blockquote cite="mid:A116E45D-A78F-43F2-B4BA-80D163E4A68B@osu.edu"
type="cite">
<pre wrap="">
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. </pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<blockquote cite="mid:A116E45D-A78F-43F2-B4BA-80D163E4A68B@osu.edu"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
<br>
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.
<blockquote cite="mid:A116E45D-A78F-43F2-B4BA-80D163E4A68B@osu.edu"
type="cite">
</blockquote>
<br>
<br>
</body>
</html>