[
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)
