[
https://issues.apache.org/jira/browse/HTRACE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15258746#comment-15258746
]
Colin Patrick McCabe commented on HTRACE-359:
---------------------------------------------
bq. This is because we lose the current scope in the new thread, right? Because
otherwise `wrap` eventually delegates to `newScope` and the behaviour should be
the same. Would it be sufficient to modify the JavaDoc, or do you think it is
better to rework it so that `wrap` and `newScope` provide similar semantics?
That would be a fairly invasive change that I would rather stay away from,
though.
I think it's fine to change the JavaDoc to make it very clear that
Tracer#wrap(... SpanId...) does NOT make use of the existing Scope (if there is
one).
It might "feel" cleaner to simply make the constructor which takes just a
SpanId public, though... and add some JavaDoc to that stating that it doesn't
use the existing Scope.
> TraceRunnable and TraceCallable should be built using parent spanId not scope
> -----------------------------------------------------------------------------
>
> Key: HTRACE-359
> URL: https://issues.apache.org/jira/browse/HTRACE-359
> Project: HTrace
> Issue Type: Bug
> Components: core
> Affects Versions: 4.0
> Reporter: Mike Drob
> Assignee: Mike Drob
> Attachments: HTRACE-359.patch.txt, HTRACE-359.patch.txt,
> HTRACE-359.v3.patch.txt
>
>
> TraceRunnable/Callable both take a parent TraceScope and extract the span Id
> from it when executing the task. Instead, we should allow users to create
> custom TraceRunnable/Callable instances with only a SpanId instead of a full
> TraceScope, for instance when reading a span id from an RPC call and a
> TraceScope object is not available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
