On restarting the instance

@Reference
private MetricRegistry metricRegistry

is satisfied, no idea why.

... although it binds to the first one loosing data in Sling.
Perhaps that also why there are no Metrics from Sling exported to JMX, only
Oak metrics, or no metrics in Sling in the version I am running.

Best Regards
Ian




On 19 January 2017 at 12:11, Ian Boston <i...@tfd.co.uk> wrote:

>
> 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
>>
>
>

Reply via email to