Service reloading manually and automatically
Cantor, Scott
cantor.2 at osu.edu
Thu May 25 19:47:59 EDT 2017
On 5/25/17, 6:57 PM, "dev on behalf of Tom Zeller" <dev-bounces at shibboleth.net on behalf of tzeller at dragonacea.biz> wrote:
> Not a big deal, but I just noticed that a reloadable service will
> still reload itself even if it was reloaded manually (via
> bin/reload-service.sh).
The reload method doesn't update any of the internal tracking of the resource times so there's no interplay between the two reload methods at all. One reason is to avoid needing any synchronization. The reload thread assumes it has sole access to the array of resource times, which is noted in a comment.
> I looked at the reloadable code, and I guess I was expecting
> ServiceableComponent to provide ReloadableService's
> getLastSuccessfulReloadInstant() or similar so that
> ReloadableSpringService could check to see if the Service was reloaded
> recently enough (maybe meaning more recently than the resources last
> modification time).
It's not just one resource. The reload thread has ugly code in it that detects when resources are added or removed, not just the relative modification time. And it doesn't compare the time the service was loaded to anything, which is why the update of that value by the manual reload doesn't affect the thread.
> Perhaps as a corollary and being picky, after the service's resource
> is modified, if the service reloads itself before the manual reload, I
> guess the manual reload could return something like "already reloaded"
> rather than reloading again. Is that the right thing ? dunno, probably
> not.
No, telling it to reload is unconditional.
My belief is: it works, the two methods don't interact *that* frequently, and an occasional extra reload doesn't hurt anything. After all the problems with this feature hanging and causing problems, having it work reliably is all I'm concerned with. I routinely reload the relying party and attribute resolver services in production with confidence now. That's too valuable to risk on any tweaks.
-- Scott
More information about the dev
mailing list