ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Annoying extra steps for enabling metrics
Date Sat, 09 Sep 2017 18:09:31 GMT
On Sat, Sep 9, 2017 at 8:56 AM, Denis Magda <dmagda@apache.org> wrote:

> Surprise!
>
> If you want to see cache events then you have to enable one more flag!
>
>  <property name="StatisticsEnabled" value="true"/>


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 is a mess. Let’s contemplate how to fix it.


Agree, this is horrible. We need to fix it in 2.3. Is there a ticket?


>
> —
> Denis
>
> > On Sep 7, 2017, at 7:33 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
> wrote:
> >
> > On Thu, Sep 7, 2017 at 7:30 PM, Denis Magda <dmagda@apache.org> wrote:
> >
> >> My point is different. Before I had to do this only assuming that
> “Ignite
> >> will spend 99%” sending events:
> >>
> >>
> >>        <property name="includeEventTypes">
> >>            <list>
> >>                <!--Task execution events-->
> >>                <util:constant static-field="org.apache.
> >> ignite.events.EventType.EVT_TASK_STARTED"/>
> >>                <util:constant static-field="org.apache.
> >> ignite.events.EventType.EVT_TASK_FINISHED"/>
> >>                <util:constant static-field="org.apache.
> >> ignite.events.EventType.EVT_TASK_FAILED"/>
> >>                <util:constant static-field="org.apache.
> >> ignite.events.EventType.EVT_TASK_TIMEDOUT"/>
> >>            </list>
> >>        </property>
> >>
> >> Now the platform forces me to do that (probably thinking that I’m crazy
> if
> >> I want to waste resources for metrics and giving one more change to
> >> contemplate the decision):
> >>
> >>        <property name="eventStorageSpi">
> >>           <bean class="org.apache.ignite.spi.eventstorage.memory.
> >> MemoryEventStorageSpi"/>
> >>       </property>
> >>
> >> Does the issue make sense to you know?
> >>
> >
> > I understand now. Why did we change this behavior? Can someone comment?
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message