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