Hi,
I followed your suggestion on using a listener and it works ok. Not too
much extra code for the reporter. No need for another API.
Thanks for the pointers.
Best Regards
Ian
On 19 January 2017 at 12:36, Ian Boston wrote:
> On restarting the instance
>
> @Reference
> private MetricRegistry met
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
Hi,
On 19 January 2017 at 11:28, Chetan Mehrotra
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 w
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 MetricR
On Thu, Jan 19, 2017 at 4:49 PM, Bertrand Delacretaz
wrote:
> @Reference
> private MetricsServiceProvider msp;
Some confusion ... there is only 1 MetricsService [1] and that too is
under Sling package namespace. So we do not need any abstraction.
Chetan Mehrotra
[1]
https://github.com/apach
On Thu, Jan 19, 2017 at 12:04 PM, Ian Boston wrote:
> ...It could be so simple to have 1 bundle exposing a service, adaptable to the
> required MetricsRegistry singleton for reporting...
IIUC what you suggest can also help with namespacing the metrics,
which is important as we add more metrics.
On Thu, Jan 19, 2017 at 4:34 PM, Ian Boston wrote:
> I also fear that there will be multiple APIs, all nearly the same,
The recommended API is the one in Sling Commons Metrics.
Oak one is internal to use in Oak and should not be used by other
components. This is because implementation in Oak pre
Hi,
On 19 January 2017 at 09:26, Chetan Mehrotra
wrote:
> On Thu, Jan 19, 2017 at 2:48 PM, Ian Boston wrote:
> >
> > Is the intention that [1] should use the same approach as [2] so that
> there
> > is 1 MetricsRegistry per JVM ?
>
> No. Sling Metrics creates and manages its own MetricRegistry
On Thu, Jan 19, 2017 at 2:48 PM, Ian Boston wrote:
>
> Is the intention that [1] should use the same approach as [2] so that there
> is 1 MetricsRegistry per JVM ?
No. Sling Metrics creates and manages its own MetricRegistry and
registers it in OSGi with a "name" service property set to "sling".
Hi,
Is the intention that [1] should use the same approach as [2] so that there
is 1 MetricsRegistry per JVM ?
ie Check for a MetricsRegistry as a service, and if not present create one,
so that there is only 1 which reporters can report on.
I am wondering how this will be made thread safe, as I
10 matches
Mail list logo
