[JIRA] Commented: (JOST-183) AbstractReloadingMetadataProvider code for maxRefreshDelay doesn't match documentation

[Brent Putman (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/JOST-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14332#comment-14332 ] 

Brent Putman commented on JOST-183:
-----------------------------------

Not realizing this issue was here, I recently just spent some time for Georgetown tracing what happens when there is no validUntil or cacheDuration in the metadata (answer: it uses now+maxRefreshDelay in step #1).  The docs don't make that sufficiently clear, I'm going to update them with at least line #1 from your second list.

Given that, I don't think #3 in the docs (first list) can ever be true.  If either validUntil or now+cacheDuration represents a time after now+maxRefreshDelay, then it wouldn't have been chosen in step #1.  And if it was chosen in step #1, then by definition it's earlier than now+maxRefreshDelay.  If now+maxRefreshDelay was chosen, then trivially it can't be later than itself. I'm going to remove this line from the docs also, unless somebody can tell me how I'm horribly wrong...

I *think* it then does in totality operate the way you describe in the second list. I'm getting a headache about now (pun intended), but are there any other open things to consider?  Are you implicitly suggesting that when the time selected in #1 is now+maxRefreshDelay, that it shouldn't multiply by refreshDelayFactor?  Off-hand I'd say it should still use refreshDelayFactor, since otherwise it means you don't attempt a refresh until the time that's stored internally as the expirationTime.  Although in my testing, the metadata isn't thrown out or treated invalid after that time passes.

> AbstractReloadingMetadataProvider code for maxRefreshDelay doesn't match documentation
> --------------------------------------------------------------------------------------
>
>                 Key: JOST-183
>                 URL: https://issues.shibboleth.net/jira/browse/JOST-183
>             Project: OpenSAML 2 - Java
>          Issue Type: Bug
>            Reporter: Rod Widdowson
>            Assignee: Chad La Joie
>            Priority: Minor
>
> So I would just go and change the documentation, but I think the doco describes a better thing than the code actually does:
> The doco says:
> 1) Determine the earliest date/time of all validUntil and cacheDuration + now
> 2) If that time is before now, schedule a refresh in minRefreshDelay + now. Stop.
> 3) If that time is after now + maxRefreshDelay, schedule the a refresh in now + maxRefreshDelay. Stop.
> 4) Compute the difference between now and time determined in step one.
> 5) Multiply that number by the refreshDelayFactor to get the delay interval
> 6) Schedule the next refresh in now + computed delay interval
> What the code does AFICS is
> 1) Determine the earliest date/time of all (validUntil) and (cacheDuration + now) and (now + maxRefreshDelay)
> 2) If that time is before now, schedule a refresh in minRefreshDelay + now. Stop.
> 3) Compute the difference between now and time determined in step one.
> 4) Multiply that number by the refreshDelayFactor to get the delay interval
> 5) Schedule the next refresh in now + computed delay interval
> I actually spotted this when testing the DS with a ridiculously short maxRefreshDelay (5 minutes) and was actually getting a refresh every 3M45S.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira