You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Alexey Scherbakov (Jira)" <ji...@apache.org> on 2021/02/09 07:41:00 UTC
[jira] [Comment Edited] (IGNITE-13393) Tracing: Atomic cache
read/write flow.
[ https://issues.apache.org/jira/browse/IGNITE-13393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281589#comment-17281589 ]
Alexey Scherbakov edited comment on IGNITE-13393 at 2/9/21, 7:40 AM:
---------------------------------------------------------------------
[~alapin]
I've left some comments in PR.
Additional questions:
1. > Agreed, however currently it's not possible to trace specified operations properly cause we don't have compute tracing
Why can't we at least trace/log the event on top level ? I see you have implemented this for removeAll operation, but not for clear. That's the reason for this ?
2. I've noticed a lot of CACHE_*_FUTURE newly introduced spans. It doesn't make sense for me to have such kind of spans, because they don't provide any useful information, tied to internal implementation (actualy, named like internal futures) and multiplies the number of traced spans. All operations should be traced on request/response level with intermediate phases. For example, cache read operation consists of map/remap and read.
Moreover, I haven't noticed such thing for transaction tracing.
In my opinion, all this spans can be removed without any drawbacks.
3. Can you provide several trace examples, for put/putAll, get/getAll, remove/removeAll, including remap phase ? It's difficult to estimate tracing flow correctness wihout having them.
4. Do we have any performance impact from this code ? At least, NOOP tracing should't have any measurable effect on this.
was (Author: ascherbakov):
[~alapin]
I've left some comments in PR.
Additional questions:
1. > Agreed, however currently it's not possible to trace specified operations properly cause we don't have compute tracing
Why can't we at least trace/log the event on top level ? I see you have implemented this for removeAll operation, but not for clear. That's the reason for this ?
2. I've noticed a lot of CACHE_*_FUTURE newly introduced spans. It doesn't make sense for me to have such kind of spans, because they don't provide any useful information, tied to internal implementation (actualy, named like internal futures) and multiplies the number of traced spans. All operations should be traced on request/response level with intermediate phases. For example, cache read operation consists of map/remap and read.
Moreover, I haven't noticed such thing for transaction tracing.
In my opinion, all this spans can be removed without any drawbacks.
> Tracing: Atomic cache read/write flow.
> --------------------------------------
>
> Key: IGNITE-13393
> URL: https://issues.apache.org/jira/browse/IGNITE-13393
> Project: Ignite
> Issue Type: New Feature
> Reporter: Alexander Lapin
> Assignee: Alexander Lapin
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Implement tracing for atomic cache operations:
> * put
> * putAll
> * putAsync
> * putAllAsync
> * remove
> * removeAll
> * removeAsync
> * removeAllAsync
> * get
> * getAll
> * getAsync
> * getAllAsync
> Also add ability to include root cache read/write operations to tx tracing flow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)