IDPv3 seems to fail to reload configuration when under heavy load.
Rod Widdowson
rdw at steadingsoftware.com
Sat Mar 2 06:07:25 EST 2019
> I'm pretty sure everything mostly reloaded in v3 by default EXCEPT new metadata.
To expand slightly: The metadata _configuration_ (metadata-providers.xml) may not be reloaded, but the _metadata_ can be. If
correctly configured if metadata at a remote (or local) location changes then it will be reloaded without needing to specify the
service as being reloadable.
Reloading all of the metadata for an IdP can be an incredibly expensive operation (multiple minutes of CPU time), and although the
IdP doesn't block during the processing you'll probably notice a slowdown.
I should also note in passing that you don't need to restart the IdP to reload large chunks of the configuration, even if that part
hasn't been marked as refreshing - there is even a command line option to do with it [1]
So if your paradigm is to add a new entity to a new file and poke the service you might want to change to some other mechanism. The
answer used to be to add the entity to an existing file. At that stage you can wait for it to auto refresh or just reload that
provider from the command line [2].
These days you would be far better served with a local dynamic metadata provider [3]. The TLDR is that you pop a file with your
metadata into a known location with a known name and magically everything just works. It cuts down you memory use as well since
unused metadata isn't loaded, and you time to restart (for the same reason),
Finally, I'd suggest you refresh yourself with the MetadataManagementBestPractices page [4]
[1] https://wiki.shibboleth.net/confluence/display/IDP30/ReloadableServices
[2] https://wiki.shibboleth.net/confluence/display/IDP30/MetadataReload
[3] https://wiki.shibboleth.net/confluence/display/IDP30/LocalDynamicMetadataProvider
[4] https://wiki.shibboleth.net/confluence/display/IDP30/MetadataManagementBestPractices
More information about the users
mailing list