<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 9/8/17 12:09 PM, Liam Hoekenga
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAH4ZtKRQN7nYY4YfOnYoC-pB46L=yojXphB6XBdxGLC02-5CSg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Can anyone shed any light on how the IDP is
deciding to reload the metadata? I guess the
periodicity is getting influenced by <span
style="color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px">refreshDelayFactor,
</span></div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
Well, in general, in the absence of an overriding validUntil or
cacheDuration in the metadata itself which dictates a *shorter*
interval, it's going to be (maxRefreshDelay * refreshDelayFactor).
That is mentioned in the refreshDelayFactor docs in the wiki that
you referenced, although maybe it's not obvious:<br>
<br>
"... Attempts to refresh metadata will generally begin around the
product of this number and the maximum refresh delay."<br>
<br>
So the default is going to be 4 hours * 0.75 = 3 hours.<br>
<br>
Note that this refresh *attempt* isn't actually necessarily going to
reload the metadata, it's merely checking to see if there is *newer*
metadata to reload, which is source-specific (for filesystem it
checks the timestamp, for HTTP it uses conditional GET).<br>
<br>
<blockquote type="cite"
cite="mid:CAH4ZtKRQN7nYY4YfOnYoC-pB46L=yojXphB6XBdxGLC02-5CSg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><span
style="color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px">but
it seems like i've got several different refresh
cycles (5?) in play.</span></div>
</div>
</blockquote>
<div><br>
</div>
<div>Is reload-metadata.sh introducing additional refresh
cycles instead of updating the one already in place?</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
Hmm. I think you have hit upon a bug, a pretty significant one in
fact. It seems it's been there since the beginning of 2.x, but only
became relevant in 3.x when we started supporting on-demand
refresh. The on-demand refresh 1) isn't cancelling the existing
next scheduled refresh task, and 2) is scheduling a next refresh of
its own. So you're seeing duplicate refresh tasks at different
intervals. I think also that once started, you will get a distinct
refresh cycle/set each time you manually invoke the refresh. The
exact details would need more research, such as how the different
cycles/sets are interacting.<br>
<br>
But yes, AFAICT, it's a major bug. I just opened an issue:<br>
<br>
<a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/OSJ-216">https://issues.shibboleth.net/jira/browse/OSJ-216</a><br>
<br>
For now, a potential workaround might be to reload the whole
metadata resolver service, rather than invoke a refresh. That will
replace the whole instance and so any existing duplicate refresh
cycles would be avoided. But of course it's more overhead, so
probably need to evaluate in light of how many metadata resolvers
you have configured and what the sources and costs are.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAH4ZtKRQN7nYY4YfOnYoC-pB46L=yojXphB6XBdxGLC02-5CSg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>If so, why do they have a shorter frequency?</div>
</div>
</div>
</div>
</blockquote>
<br>
That I'm not sure about off-hand. Probably some non-obvious
interaction between the distinct cycles/sets of scheduled refresh
tasks. Also, you didn't mention whether the metadata has a root
validUntil or cacheDuration, but that also influences the refresh
cycle (um, cycles).<br>
<br>
</body>
</html>