forced refresh of SP metadata when using mdq
Paul B. Henson
henson at acm.org
Sat Feb 22 02:57:37 UTC 2025
I've got a client that is past due on migrating from the legacy bulk
aggregate to MDQ on their SP; the recent oopsie with the validity
interval (which didn't impact them as they had happened to extend that
configuration value to longer than three weeks in the past) was a
wake-up call that brought the issue to their attention.
I'm trying to sort out a question they have regarding how to force the
SP to refresh cached metadata and was hoping someone might know offhand
so I could avoid code spelunking :).
How long something lives in the cache appears to be a factor of the
source metadata validity interval, the maxCacheDuration configuration
value and the refreshDelayFactor. As incommon metadata validity will
always be two weeks (unless it isn't ;) ), and maxCacheDuration will
almost always be less than that, metadata will generally live in the
cash for approximately maxCacheDuration.
Hypothetically, say maxCacheDuration is set to four hours, and the
metadata for a particular entity happens to be loaded one minute before
incommon updates. Some customer made an urgent change they want an SP to
reflect ASAP. Short of shutting down the SP, deleting the cached entry
from the cache directory, and restarting the SP, is there any way to
dynamically get the running SP to refresh that specific metadata
immediately without impacting its operation or other metadata? It would
probably be fine to force it to refresh all cached metadata as long as
that did not involve a disruption in service to do so.
The configuration itself is dynamically reloadable, so it seems
potentially a kludgy way to do it might be to take a metadata provider
in the existing config:
<MetadataProvider type="MDQ" id="incommon" ignoreTransport="true"
cacheDirectory="inc-mdq-cache"
maxCacheDuration="86400" minCacheDuration="60"
baseUrl="https://mdq.incommon.org/">
<MetadataFilter type="Signature" certificate="inc-md-cert-mdq.pem"/>
<MetadataFilter type="RequireValidUntil" maxValidityInterval="1209600"/>
</MetadataProvider>
and change the id and the cacheDirectory attributes so the SP thinks
it's effectively a different metadata provider hence abandoning all of
the existing cached entries associated with the "previous" one?
Thanks much for any insight on this issue…
More information about the users
mailing list