Add per-entity observability for metadata providers
Description
Environment
Activity
Scott Cantor March 21, 2018 at 7:04 PM
Closing this for now, I don't think any further improvements are worth the work right now.
Scott Cantor January 19, 2018 at 1:33 AM
First change made, XMLAttributeExtractor cache is now based on entityID, so if the event notifications are per-entity, it will only invalidate cache for that entityID.
This also required turning off caching for Attributes extracted from an EntitiesDescriptor, and changing the cache option to default false to prevent very unlikely problems with overlapping metadata sources.
Scott Cantor January 18, 2018 at 9:32 PM
On second thought I really don't like how some of this works anyway and would like to revisit some of it. One thought is we should investigate new metadata filtering that might populate some kind of object extension.
Scott Cantor January 16, 2018 at 5:07 PM
I looked into the couple of cases where the caching actually gets used, and it's principally the PKIX key resolver and the attribute extraction layer. I don't think either one warrants all the work it would take to fix the cache invalidation, though it is inefficient.
Scott Cantor November 10, 2011 at 8:46 PM
Related to this, the metadata API should be extended with the ability to hang "note" data off of particular entities with the cleanup managed via callback by the provider itself. That reduces the need to cache information using external eventing.
Current eventing for metadata updates is per-provider, but the dynamic metadata support works much better with per-entity eventing. Should be possible to extend the Observable APIs with an Ex version that adds per-entity notifications and limit cache dumps.