ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Kuznetsov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations
Date Thu, 30 Nov 2017 16:05:00 GMT

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 11/30/17 4:04 PM:
--------------------------------------------------------------------

[~vkulichenko] Ok, Im going to rework API.
And make 'invoke' metrics be calculated the similar way as corresponding regular cache operations(invoke
remove metrics equals regular removes metrics, and so on.)
There will be problems with implementing "getAverageEntryProcessorReadOnlyInvocationTime();"
metric, because we don't know whether invoke is read-only or not on initiating node(node,
initiated invoke operation, and waiting for invoke response from cluster)

9)Assume we have 3 operations in EntryProcessor.invoke() :
{code:java}
                cache0.invoke(i, new CacheEntryProcessor<Integer, Integer, Object>()
{
                    @Override public Object process(MutableEntry<Integer, Integer> entry,
                        Object... arguments) throws EntryProcessorException {
                        entry.getValue();

                        entry.setValue(1);

                        entry.remove();
                        return null;
                    }
                });
{code}
Effective result of invoking is empty removal.
So, *only* 'invoke removal' metric will be incremented, am I right ?

10) In *empty* ATOMIC PARTITIONED cache.
      We are calling cache.remove(someKey), and *regular* 'remove' metric *is incremented*
on primary node A.
      If we invoke processor, which do entry.remove() , than *regular* 'remove' metric is
*not incremented* on primary node A.
So, in this case 'invoke remove' metric should be incremented on node A, am I right ?

If its true, than incrementing 'invoke remove' metric would be very non-trivial task.


was (Author: alexey kuznetsov):
[~vkulichenko] Ok, Im going to rework API.
And make 'invoke' metrics be calculated the similar way as corresponding regular cache operations(invoke
remove metrics equals regular removes metrics, and so on.)
There will be problems with implementing "getAverageEntryProcessorReadOnlyInvocationTime();"
metric, because we don't know whether invoke is read-only or not on initiating node(node,
initiated invoke operation, and waiting for invoke response from cluster)

9)Assume we have 3 operations in EntryProcessor.invoke() :
{code:java}
                cache0.invoke(i, new CacheEntryProcessor<Integer, Integer, Object>()
{
                    @Override public Object process(MutableEntry<Integer, Integer> entry,
                        Object... arguments) throws EntryProcessorException {
                        entry.getValue();

                        entry.setValue(1);

                        entry.remove();
                        return null;
                    }
                });
{code}
Effective result of invoking is empty removal.
So, *only* 'invoke removal' metric will be incremented, am I right ?

10) In *empty* ATOMIC PARTITIONED cache.
      We are calling cache.remove(someKey), and *regular* 'remove' metric *is incremented*
on primary node A.
      If we invoke processor, which do entry.remove() , than *regular* 'remove' metric is
*not incremented* on primary node A.
So, in this case 'invoke remove' metric should be incremented on node A, am I right ?

> Add metrics for entry processor invocations
> -------------------------------------------
>
>                 Key: IGNITE-6846
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6846
>             Project: Ignite
>          Issue Type: Improvement
>          Components: cache
>    Affects Versions: 2.3
>            Reporter: Valentin Kulichenko
>            Assignee: Alexey Kuznetsov
>            Priority: Critical
>              Labels: iep-6
>             Fix For: 2.4
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations like {{get}},
{{put}} and {{remove}}, but nothing for {{invoke}}/{{EntryProcessor}}. It makes sense to add
such metrics, for example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message