Questions about o.a.s.commons.metrics and SLING-5965

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

I had a look at SLING-5965, this looks useful but raised two
questions, mostly because I'm not yet familiar with the new
o.a.s.commons.metrics that Chetan introduced.

1) Is it generally ok for Gauge.getValue() (for example, as this is
what this code uses) to have to do some work to produce a value, as
opposed to accumulating values earlier.

With the current SLING-5965 patch, getValue()  takes more time the
more jobs are present. The alternative might be to just store the N
oldest job starting times.

Creating load while retrieving metrics looks risky to me in general as
it's when your system is in trouble that you might request those
metrics the most.

2) Does the metrics library by default make all values available via
JMX as well?

-Bertrand

Re: Questions about o.a.s.commons.metrics and SLING-5965

[Stefan Egli <st...@apache.org>]

Hi,

On 16/08/16 13:51, "Stefan Egli" <st...@apache.org> wrote:

>>2) Does the metrics library by default make all values available via
>>JMX as well?
>
>That I don't know, couldn't find it at least.

FYI: due to SLING-5424 (jmxReporter not started) this indeed doesn't work
in commons.metrics-1.0.0 yet, only in 1.0.2 (not yet released). Albeit
with an empty (JMX) 'Type' - which seems to be due to [1] not using a
custom ObjectNameFactory as [0] does. So perhaps we should also use such a
factory for commons metrics?

Cheers,
Stefan
--
[0] 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/
org/apache/jackrabbit/oak/plugins/metric/MetricStatisticsProvider.java#L77
[1] 
https://github.com/apache/sling/blob/trunk/bundles/commons/metrics/src/main
/java/org/apache/sling/commons/metrics/internal/MetricsServiceImpl.java#L21
5

Re: Questions about o.a.s.commons.metrics and SLING-5965

[Stefan Egli <st...@apache.org>]

Hi Bertrand,

On 16/08/16 13:41, "Bertrand Delacretaz" <bd...@apache.org> wrote:

>With the current SLING-5965 patch, getValue()  takes more time the
>more jobs are present. The alternative might be to just store the N
>oldest job starting times.

By default we have 2 thread pools (schedulers) and invoking
getCurrentlyExecutingJobs on each of them returns only those really
running - which are capped by the thread pools. So I don't think this is a
performance issue.

>Creating load while retrieving metrics looks risky to me in general as
>it's when your system is in trouble that you might request those
>metrics the most.

Agreed - if there is indeed load. As I see it however (s.above) that's not
the case. And calculating something in the background all the time, vs
only when it's needed seems less performant to me.

>2) Does the metrics library by default make all values available via
>JMX as well?

That I don't know, couldn't find it at least.

Cheers,
Stefan

Re: Questions about o.a.s.commons.metrics and SLING-5965

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Aug 16, 2016 at 3:23 PM, Chetan Mehrotra
<ch...@gmail.com> wrote:
> ..the way we have configured it in Sling Commons Metrics all
> Metrics are exposed over JMX also..

Great! Thanks Stefan and Chetan for the clarifications, all looks good to me.

-Bertrand

Re: Questions about o.a.s.commons.metrics and SLING-5965

[Chetan Mehrotra <ch...@gmail.com>]

On Tue, Aug 16, 2016 at 5:11 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> 1) Is it generally ok for Gauge.getValue() (for example, as this is
> what this code uses) to have to do some work to produce a value, as
> opposed to accumulating values earlier.

Gauge.getValue() should be fast and kind of O(1). As Stefan mentioned
here its not that costly. If we need to optimize we can probably use
PriorityQueue within a JobListener to keep it upto date

> Does the metrics library by default make all values available via
JMX as well?

Yes they way we have configured it in Sling Commons Metrics all
Metrices are exposed over JMX also

Chetan Mehrotra