Hi,
On 19 January 2017 at 11:28, Chetan Mehrotra <chetan.mehro...@gmail.com>
wrote:
> Thinking further I think Ian's problem is around dealing with multiple
> MetricRegistry instance for each reporter implementation. I think that
> we can simplify by providing a MetricRegistryProvider which provides a
> registry instance which contains metrices from all MetricRegistries
>
> interface MetricRegistryProvider {
> MetricRegistry getMetricRegistry()
> }
>
> Something like this can be implemented on top of [1].
>
> If that is the case then please open an issue for that.
>
The above is my immediate problem.
MetricRegistryProvider.getMetricRegistry would fix that.
I would no use listeners. I would extend MetricsRegistry (its not final)
and override
protected ConcurrentMap<String, Metric> buildMap() {
return new ConcurrentHashMap();
}
replacing new ConcurrentHashMap() with a ConcurrentMap that aggregates the
metrics metrics value of all MetricsRegistries currently registered. That
way, no mess is left behind from bundles that are unloaded.
-----------------------------------------
In the version of 1.6-SNAPSHOT I am testing against, no the MetricsRegistry
is exported as a service from MetricsStatisticsProvider and the method to
get hold of it is not part of the StatisticsProvider API. I can get round
this with reflection, and I can write a component to detect the condition,
extract the MetricsRegisrty and register it. (a hack).
Without this
@Reference
private MetricRegistry metricRegistry
remains unsatisfied.
I assume without a backport that will be true for 1.5.x,1.4.x, etc versions
of Oak in production.
If the Sling commons Metric bundle is the source of truth for Metrics, then
Oak should use it and not create its own.
Isnt that why we all use OSGi?
Best Regards
Ian
>
> Chetan Mehrotra
> [1] https://github.com/bdelacretaz/sling-adaptto-
> 2016/blob/master/sling-images/bundles/metrics-es-reporter/
> src/main/java/ch/x42/sling/at16/internal/MetricCopyingListener.java#L36
>
