You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Nikolay Izhikov (JIRA)" <ji...@apache.org> on 2019/07/17 08:29:00 UTC

[jira] [Comment Edited] (IGNITE-11927) [IEP-35] Add ability to enable\disable subset of metrics

    [ https://issues.apache.org/jira/browse/IGNITE-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16886762#comment-16886762 ] 

Nikolay Izhikov edited comment on IGNITE-11927 at 7/17/19 8:28 AM:
-------------------------------------------------------------------

Hello, Andrey.

> 2. We enable or disable metrics for one source of metrics. So we can just remove MetricRegistry from GridMetricManager when metrics disabled.
 > 3. There is no need for disabled flag in MetricRegistry. As we discused early, when metric disabled they don't consume any memory. MetricsRegistry should be collected by GC. After enabling it can be created and registered into GridMetricManager again.

I don't understand your proposal.

Metric instances are stored as a class field in the places where they updated.
You can take a {{GridJobProcessor}} or {{CacheMetricImpl}} as examples.

How and why we should clear these variables on disabling?
Can you provide simple pseudo code for disable\enable processing.

> 4. Please, separate buckets configuration and metrics enabling/disabling into two different tickets.

OK

> 5. Please, create review in Upsource.

https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1061

> 6. Please, run TC and take a look to results before code review.

https://ci.ignite.apache.org/viewQueued.html?itemId=4343158


was (Author: nizhikov):
Hello, Andrey.

> 2. We enable or disable metrics for one source of metrics. So we can just remove MetricRegistry from GridMetricManager when metrics disabled.
 > 3. There is no need for disabled flag in MetricRegistry. As we discused early, when metric disabled they don't consume any memory. MetricsRegistry should be collected by GC. After enabling it can be created and registered into GridMetricManager again.

I don't understand your proposal.

Metric instances are stored as a class field in the places where they updated.
You can take a {{GridJobProcessor}} or {{CacheMetricImpl}} as examples.

How and why we should clear these variables on disabling?
Can you provide simple pseudo code for disable\enable processing.

> 4. Please, separate buckets configuration and metrics enabling/disabling into two different tickets.

OK

> 5. Please, create review in Upsource.

https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1061

> 6. Please, run TC and take a look to results before code review.

In progress: https://ci.ignite.apache.org/viewLog.html?buildId=4343042&

> [IEP-35] Add ability to enable\disable subset of metrics
> --------------------------------------------------------
>
>                 Key: IGNITE-11927
>                 URL: https://issues.apache.org/jira/browse/IGNITE-11927
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Nikolay Izhikov
>            Assignee: Nikolay Izhikov
>            Priority: Major
>              Labels: IEP-35
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Ignite should be able to:
> * Enable or disable an arbitrary subset of the metrics. User should be able to do it in runtime.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)