expirationWarningThreshold

Brent Putman putmanb at georgetown.edu
Sat May 13 23:23:37 EDT 2017



On 5/13/17 8:26 PM, Tom Scavo wrote:
> What exactly is a "completed metadata refresh?" I assume that does not
> include an attempted metadata refresh that was short-circuited via
> HTTP Conditional GET, correct?

No, it includes literally every refresh cycle.  The eval is done at the
end of the refresh() call, regardless of what did or did not happen
during the refresh.

The issue is: https://issues.shibboleth.net/jira/browse/OSJ-200

The main use case that prompted Scott to open the issue is precisely
what you mentioned above:  No new metadata bytes were fetched b/c they
haven't changed - BUT the metadata is either expired or in danger of
expiring "soon".

So now at the end of the refresh we check the live batch root
validUntil, and log a WARN on three cases:

1) metadata is already expired or otherwise invalid
2) it's going to expire within the configured expirationWarningThreshold
3) it's going to expire before the next scheduled refresh


> Presumably, an appropriate setting for expirationWarningThreshold will
> depend on the values of the other configuration parameters. 

I suppose that's true, although I think you also need to factor in
knowledge about the "expected" validity duration of the metadata source.


> Suppose a
> reloading metadata provider is configured to refresh metadata at least
> daily. If validUntil is 14 days in the future, then the
> expirationWarningThreshold should be set to PT13D, right?

I'm not sure about that.  The point of the WARN log is to have
proactive notification of when something goes wrong.  For example, the
metadata publisher's process stops working, or the publishing endpoint
stops responding, etc.  So the "typical" validUntil isn't really the
main concern here.


> I'm probably not understanding something since the default value is
> just PT12H.

As we discussed there at the end of the Jira issue, there's really
probably no good default, since it really depends on how often the
resolver refresh runs as well as what the typical validity duration is.

The value really is probably "How much time in advance of a potential
expired metadata situation do you want to see a WARN log, so you can
intervene and do something about it?"


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170513/6c846576/attachment.html>


More information about the dev mailing list