Affects Version/s: 4.0.0
Fix Version/s: 4.0.0
This springs from a side conversation in
It turns out that both the MetadataProvider Service and the Attribute Resolver Service both have reloadable subsystems. Metadata providers can track
The reloadable metadata providers use this to control whether a metadata lookup should trigger a reload.
Are Attribute Resolver tracks
The Attribute resolver uses this to work out whether it is in a failed status (thus whether the failover connector is active and for how long it needs to remain active).
This is all very good.
But then we come to status reporting and each of these get plugged into the gauges we export and are also exported to status.jsp
This came to our attention because status.jsp dives into the attribute resolver to grab the data connectors to grab the last fail time for each data connector. Then it dives into the metadata providers for the above (which at least are usefully combined into a RefreshableMetadatInstant.
This is all useful information we we need to make it available, but I don't like that the attribute resolver exports its data connectors and I don't like ir that the status page assumes that only data connectors can fail. I can live with it, but I'd be happier if both the attribute resolver and the metadata resolver exported a Set<ReloadableChild> where ReloadableChild was some sort of glomming together of the above two. This would devolve the work out of from the metrics and the status page and into the resolvers (which is kinda where they belong).
But I have to be leery of over complication. And although the basic ideas are similar the details of the implementations differ (not least because metadata providers cascade, data connectors don't)