For JMX I intended to address SLING-5443 which so far I have not been
able to work upon. Also for SLING-5965 we would need to add Gauge
support SLING-5966
I would try to get some time to work on that but cannot commit on that
due to other work
Chetan Mehrotra
On Mon, Aug 22, 2016 at 9:29 PM, St
Hi,
For SLING-5965 I'd need SLING-5424 - ie commons.metrics 1.0.2 released.
That currently still has 3 open issues. Anything preventing those from
being moved to 1.0.4 and releasing 1.0.2 now?
Cheers,
Stefan
On 18/08/16 11:39, "Stefan Egli" wrote:
>Hi,
>
>On 16/08/16 13:51, "Stefan Egli" wrot
Hi,
On 16/08/16 13:51, "Stefan Egli" 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.
On Tue, Aug 16, 2016 at 3:23 PM, Chetan Mehrotra
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
On Tue, Aug 16, 2016 at 5:11 PM, Bertrand Delacretaz
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 St
Hi Bertrand,
On 16/08/16 13:41, "Bertrand Delacretaz" 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
getCurren
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
