On Wed, Aug 31, 2016 at 2:58 PM, Bertrand Delacretaz
wrote:
> Is the activation of that NOOP implementation configurable, or should
> we make it configurable?
That would need to be implemented
Chetan Mehrotra
On Wed, Aug 31, 2016 at 11:16 AM, Chetan Mehrotra
wrote:
> On Wed, Aug 31, 2016 at 2:40 PM, Bertrand Delacretaz
> wrote:
>> ...this shows the need for our core to optionally work with
>> metrics disabled
>
> Thats possible with Sling Metrics
On Wed, Aug 31, 2016 at 2:40 PM, Bertrand Delacretaz
wrote:
> Good point, this shows the need for our core to optionally work with
> metrics disabled
Thats possible with Sling Metrics where it can register a NOOP
implementation without requiring api clients to do any
Hi,
On Wed, Aug 31, 2016 at 10:49 AM, Ian Boston wrote:
> ...I am not certain how Metrics 3.1 behaves when run on a non Sun JDK...
Good point, this shows the need for our core to optionally work with
metrics disabled, for the worst case where such implementations are
not
+1
The underlying impl which is IIRC Codehale metrics used sun.misc.Unsafe pre
3.2 fixed in [1]. It should be updated once 3.2 is updated. I am not
certain how Metrics 3.1 behaves when run on a non Sun JDK. I think it falls
back to a slower impl of Stripe64 that doesn't use Unsafe internally.
I
+1. This would be useful
Some ideas on what metrics need to be collected at mentioned in SLING-5410.
Chetan Mehrotra
On Wed, Aug 31, 2016 at 1:56 PM, Bertrand Delacretaz
wrote:
> Hi,
>
> Shall we generally add metrics [1] to our core?
>
> I have a student at $work that
Hi,
Shall we generally add metrics [1] to our core?
I have a student at $work that needs to do a small project, I thought
they could contribute to that, including creating a demo setup with
some visualization tool.
We'd need to define guidelines for which metrics to add where but
that's a good