Re: Annoying extra steps for enabling metrics

Ok, then I will rename methods to setEventsDisabled/getEventsDisabled. 2018-02-01 12:46 GMT+03:00 Anton Vinogradov : > Folks, > > .setEventsDisabled looks to be a good solution, since we will always call > it like .setEventsDisabled(true). > > Calling .setEventsEnabled(false), since true is a de

Re: Annoying extra steps for enabling metrics

Folks, .setEventsDisabled looks to be a good solution, since we will always call it like .setEventsDisabled(true). Calling .setEventsEnabled(false), since true is a default, looks odd to me. On Wed, Jan 31, 2018 at 11:02 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Alex, >

Re: Annoying extra steps for enabling metrics

Alex, As a workaround, you can use boxed Boolean as a field type, and then return true from getEventsEnabled in case it's null. Will this work? -Val On Wed, Jan 31, 2018 at 7:31 AM, Alex Plehanov wrote: > Denis, there is a question about IGNITE-7346. > > CacheConfiguration fields are set to th

Re: Annoying extra steps for enabling metrics

Denis, there is a question about IGNITE-7346. CacheConfiguration fields are set to they default values when cache configuration is created by constructor. When CacheConfiguration is created by deserialization (from another node or from PDS), constructor is not called. If it was serialized by older

Re: Annoying extra steps for enabling metrics

Due to holidays I can start work on this ticket only after 8 jan 2018 2017-12-30 2:12 GMT+03:00 Denis Magda : > Good, closed the original ticket. > > Alex P, do you have time to work on IGNITE-7346 instead to address the > issue with the cache events per cache in 2.4 release? > > — > Denis > > >

Re: Annoying extra steps for enabling metrics

Good, closed the original ticket. Alex P, do you have time to work on IGNITE-7346 instead to address the issue with the cache events per cache in 2.4 release? — Denis > On Dec 29, 2017, at 3:10 PM, Valentin Kulichenko > wrote: > > Agree. > > -Val > > On Fri, Dec 29, 2017 at 3:08 PM, Denis

Re: Annoying extra steps for enabling metrics

Agree. -Val On Fri, Dec 29, 2017 at 3:08 PM, Denis Magda wrote: > Now I see. Seems I was doing something wrong in my initial reproducer. > > Updated cache metrics readme doc by purging any events related parameters > from there: > https://apacheignite.readme.io/v2.3/docs/cache-metrics < > https

Re: Annoying extra steps for enabling metrics

Now I see. Seems I was doing something wrong in my initial reproducer. Updated cache metrics readme doc by purging any events related parameters from there: https://apacheignite.readme.io/v2.3/docs/cache-metrics The events readme doc look

Re: Annoying extra steps for enabling metrics

Valentine, yes, that's exactly what I'm trying to say. I don't see direct dependencies between these properties (when a property must be set in all cases another property is set). 2017-12-29 22:10 GMT+03:00 Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Guys, > > I'm not sure what issue

Re: Annoying extra steps for enabling metrics

Guys, I'm not sure what issue we're trying to solve. Basically, we have three different functionality parts here: 1. Cache metrics exposed via CacheMetrics interface and MBeans (number of puts, average put time, this kind of stuff). These are controlled on per cache level by CacheConfiguration#st

Re: Annoying extra steps for enabling metrics

Alexey, I think we should enable memoryEventStorageSPI automatically whenever statisticsEnabled is toggled on. A special message has to be added to the log pointing out that the automatic activation happened. Does it sound like a good solution? — Denis > On Dec 29, 2017, at 3:51 AM, Alexey P

Re: Annoying extra steps for enabling metrics

Denis, I start working on the issue https://issues.apache.org/jira/browse/IGNITE-6925 and now I don't understand why these properties must be bound to each other? • If we enable statistics on caches, this does not necessarily mean, that we wanted to get some events, we can enable statistics for o

Re: Annoying extra steps for enabling metrics

Let’s simplifying the metrics as a part of this ticket: https://issues.apache.org/jira/browse/IGNITE-5796 Expanded its scope. — Denis > On Sep 9, 2017, at 2:44 PM, Valentin Kulichenko > wrote: > > statisticsEnabled property comes from JCach

Re: Annoying extra steps for enabling metrics

statisticsEnabled property comes from JCache, BTW. -Val On Sat, Sep 9, 2017 at 11:09 AM, Dmitriy Setrakyan wrote: > On Sat, Sep 9, 2017 at 8:56 AM, Denis Magda wrote: > > > Surprise! > > > > If you want to see cache events then you have to enable one more flag! > > > > > > > What is the over

Re: Annoying extra steps for enabling metrics

On Sat, Sep 9, 2017 at 8:56 AM, Denis Magda wrote: > Surprise! > > If you want to see cache events then you have to enable one more flag! > > What is the overhead of this statistics collection? > Three flags/beans have to be in the config in total, three! Just to see > cache events. The API

Re: Annoying extra steps for enabling metrics

Surprise! If you want to see cache events then you have to enable one more flag! Three flags/beans have to be in the config in total, three! Just to see cache events. The API is a mess. Let’s contemplate how to fix it.

Re: Annoying extra steps for enabling metrics

First of all, these are events, not metrics, and to my knowledge Ignite itself does not expose any metrics that depend on events. The fact that Web Console (or any other tool) uses events to track and show something is a different story. Events API has two parts: listening (one simply registers a

Re: Annoying extra steps for enabling metrics

On Thu, Sep 7, 2017 at 7:30 PM, Denis Magda wrote: > My point is different. Before I had to do this only assuming that “Ignite > will spend 99%” sending events: > > > > > > > > > >

Re: Annoying extra steps for enabling metrics

My point is different. Before I had to do this only assuming that “Ignite will spend 99%” sending events: Now the platform forces me to do that (probably thinking tha

Re: Annoying extra steps for enabling metrics

On Thu, Sep 7, 2017 at 7:19 PM, Denis Magda wrote: > Any metric from of org.apache.ignite.events.EventType (cache operations, > compute, etc.) > If you enable them all, Ignite will spend 99% of its time doing event notifications. > > — > Denis > > > On Sep 7, 2017, at 7:15 PM, Dmitriy Setrakya

Re: Annoying extra steps for enabling metrics

Any metric from of org.apache.ignite.events.EventType (cache operations, compute, etc.) — Denis > On Sep 7, 2017, at 7:15 PM, Dmitriy Setrakyan wrote: > > Denis, which metrics are you talking about? > > On Thu, Sep 7, 2017 at 7:12 PM, Denis Magda wrote: > >> Igniters, >> >> It was a surpri

Re: Annoying extra steps for enabling metrics

Denis, which metrics are you talking about? On Thu, Sep 7, 2017 at 7:12 PM, Denis Magda wrote: > Igniters, > > It was a surprise for me to reveal that even if the default config is used > [1] I still will not see the metrics in Web Console or in a custom app. > However, the config was left uncha

Annoying extra steps for enabling metrics

Igniters, It was a surprise for me to reveal that even if the default config is used [1] I still will not see the metrics in Web Console or in a custom app. However, the config was left unchanged for a while and from the first look encompassed everything we need to start getting metrics. But,