IGNITE-4799 MetricsUpdate after each job

[Sasha Belyak]

Now IgniteConfiguration.MetricsUpdate now can be:
-1 - disabled
0 - collect after each job
>0 - collect after specified amount in ms.
If we will use this parameter to send metrics - we should remove this
options and leave only >0 values available. Should I remove any 0 and -1
mentions in 4799?

[yzhdanov]

Denis M,

Can you please elaborate on this?
Currently org.apache.ignite.configuration.IgniteConfiguration#getMetricsUpdateFrequency
has special values like 0 and -1 that hardly make sense if we use this
parameter in discovery to issue metrics updates.

I would agree with Sasha and interpret this parameter as delay between
metrics update messages thus making 0 and -1 illegal.

Thanks!

--Yakov

[dmagda]

Yasha, Sergey,

As far as I recall discovery SPI exchanges not only compute metrics but cache metrics as well over the cluster ring.

Presently, org.apache.ignite.configuration.IgniteConfiguration#getMetricsUpdateFrequency is compute metrics oriented (at least the javadoc says this). After we use this parameter for the all metrics exchanged over discovery we need update the javadoc and, obviously, discontinue 0 as a possible value because I don’t see how to apply it for cache metrics. Does it make sense to you?

—
Denis

> On Apr 17, 2017, at 6:02 AM, Yakov Zhdanov <[hidden email]> wrote:
>
> Denis M,
>
> Can you please elaborate on this?
> Currently org.apache.ignite.configuration.IgniteConfiguration#getMetricsUpdateFrequency
> has special values like 0 and -1 that hardly make sense if we use this
> parameter in discovery to issue metrics updates.
>
> I would agree with Sasha and interpret this parameter as delay between
> metrics update messages thus making 0 and -1 illegal.
>
> Thanks!
>
> --Yakov

[yzhdanov]

Denis, thanks! That makes sense to me.

Sasha, please go ahead and change code to interpret this parameter as exact
frequency in milliseconds.

--
Yakov Zhdanov