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