Align Refresh child refresh status reporting between MetadataProviders and AttributeResolvers
Description
Environment
Activity
Rod Widdowson July 24, 2019 at 2:26 PM
Nothing more to do
Rod Widdowson June 16, 2019 at 3:28 PM
First attempt at doing this using gauges is checked in, but there are some wrinkles:
Because we always want this to work we use the raw Gauges built in
general-admin-system.xml. If we didn't then the deployer could filter out the results. Of course that might be what they want, but if they did why would then then be using this page and not the general admin page?The current status code will report about every known sub-service (Metadata Resolver or Data Connector). The Gauges only record non null dates. so
We only report Data Connectors that have ever failed (saying "No Data Connector has ever failed" if none have). This means that static data connectors are never reported.
We only report Metadata Resolvers that have tried at least once to refresh (saying "No Metadata Resolver has ever attempted a reload" if none have)
The rest of the reporting is done from the services interface not via the gauges (even for attribute resolution and metadata resolution where we have the info in a gauge).
It would be possible to recode the whole thing using the deployer specified registry and gauges and nothing else, but would that bring any benefit over and above what we have ? Apart from being jsp code to duplicate the existing admin flow - Remember that the only motivation here is to stop us exposing an impl class in our jsp (which we have achieved).
I can be argued out of any of the above positions. If no counter arguments occur I'll close this in a week or so.
Rod Widdowson June 7, 2019 at 2:45 PM
Discussion 6/6
There is probably not enough common ground to make this sharable
But can we replace the status page with something that uses with Guages and Metrics
But do not waste too much time...
This springs from a side conversation in IDP-1121.
It turns out that both the MetadataProvider Service and the Attribute Resolver Service both have reloadable subsystems. Metadata providers can track
LastSuccessfulReloadInstant
LastReloadAttemptInstant
RootValidUntil
ReloadFailureCause
The reloadable metadata providers use this to control whether a metadata lookup should trigger a reload.
Are Attribute Resolver tracks
LastFail
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)