-
Notifications
You must be signed in to change notification settings - Fork 232
Add a ActiveSpanSource backed TraceContext #266
Conversation
- use `ActiveSpanSource` for propagation instead of `ThreadLocalTraceContext` Signed-off-by: Prithvi Raj <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #266 +/- ##
============================================
- Coverage 82.3% 82.29% -0.01%
- Complexity 530 535 +5
============================================
Files 87 87
Lines 2006 2022 +16
Branches 237 237
============================================
+ Hits 1651 1664 +13
- Misses 258 260 +2
- Partials 97 98 +1
Continue to review full report at Codecov.
|
private Span getSpan(ActiveSpan activeSpan) { | ||
Span wrappedSpan; | ||
try { | ||
wrappedSpan = (Span) ActiveSpanSourceTraceContext.wrappedSpan.get(activeSpan); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unnecessary qualifier ActiveSpanSourceTraceContext.
/** | ||
* This is a hack to retrieve the span wrapped by the {@link ThreadLocalActiveSpan} implementation | ||
* to shoehorn into the {@link TraceContext} implementation. This is being done so that | ||
* instrumentation relying on {@link Tracer} has a is consistent with instrumentation using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: "has a is"
|
||
private final Tracer tracer; | ||
/** | ||
* This is a hack to retrieve the span wrapped by the {@link ThreadLocalActiveSpan} implementation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's mention that this is a temporary hack until 0.31
* This is a {@link TraceContext} that relies on the {@link ActiveSpanSource} registered with {@link | ||
* GlobalTracer}. | ||
*/ | ||
public class ActiveSpanSourceTraceContext implements TraceContext { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure we need a new class instead of changing ThreadLocalTraceContext? If someone is already using ThreadLocalTraceContext directly, then it won't work correctly any longer, so I think it warrants a breaking API change (namely having an argument to the constructor).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also simply remove the ThreadLocalTraceContext
instead of marking it @Deprecated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why create extra churn with classes/filenames/history when we can reuse the same class and re-implement it as needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you provide justification for sticking with the old name?
The new name is more descriptive.
Javac itself doesn't care about what this class used to be called.
As far as git goes, it uses binary blobs to track file content. I expect it to be able to handle this operation efficiently. Have you seen examples where it hasn't? Should we be optimizing for git history size?
} | ||
} | ||
|
||
public ActiveSpanSourceTraceContext(Tracer tracer) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I think you can use a more narrow dependency, ActiveSpanSource instead of Tracer.
- instead of depending on ActiveSpanSource, it makes sense to depend directly on ThreadLocalActiveSpanSource
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of depending on ActiveSpanSource, it makes sense to depend directly on ThreadLocalActiveSpanSource
This is a bit involved because we need to use reflection to get the instance of the ThreadLocalActiveSpanSource
from the tracer. I updated to use the ActiveSpanSource
interface instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you don't need reflection, just a cast: (ThreadLocalActiveSpanSource) tracer.activeSpanSource()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tracer.activeSpanSource
isn't public. Further, it is defined in com.uber.jaeger.Tracer
in jaeger-core
, for which we'd have to add a dependency from jaeger-context
instead of depending on opentracing-api
.
if (!GlobalTracer.isRegistered()) { | ||
throw new IllegalStateException("Please register a io.opentracing.util.GlobalTracer"); | ||
} | ||
traceContext = new ActiveSpanSourceTraceContext(GlobalTracer.get()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am concerned with the race conditions here, as you don't know whether TracingUtils class will be loaded before we have a chance to init global tracer. You may need to change this into a lazy dependency, i.e. instead of passing tracer (or active span source, per the other comment) to the TraceContext impl, you mass a function that returns an active span source, so that it's dereferenced as needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought this was was fine because GlobalTracer.get()
returns an instance that is a new reference to itself. However, I agree that we cannot guarantee that TracingUtil is loaded after the tracer is initialized. I'll move this to a lazy init block.
|
||
Tags.HTTP_STATUS.set(serverSpan, containerResponseContext.getStatus()); | ||
serverSpan.finish(); | ||
traceContext.pop(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please add comments explaining this order (i.e. that we cannot call pop
as before since it will deactivate & finish the span).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this the only place in the whole project where we call pop
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do. No, we call it in our wrapped Callable and Runnable
Signed-off-by: Prithvi Raj <[email protected]>
Signed-off-by: Prithvi Raj <[email protected]>
return new TracedExecutorService(wrappedExecutorService, traceContext); | ||
} | ||
|
||
private TracingUtils(){} | ||
private static synchronized void initializeTraceContext() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in my suggestion there was no additional synchronized
on the hot path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I apologize, I didn't understand your previous suggestion, could you elaborate?
As such, getTraceContext
and tracedExecutor
are only used when initializing filters and executors. I expect these methods to be called a handful of times during application startup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of ActiveSpanSourceTraceContext(Tracer)
declare ActiveSpanSourceTraceContext(TracerProvider tracerProvider)
and then in the implementation every time you need a tracer you retrieve it dynamically viatracerProvider.get()
, which will delegate to GlobalTracer.get()
. This way you leave a lot more opportunities to the application to init the global tracer before it stumbles on the need to push/pop spans into TraceContext
Signed-off-by: Prithvi Raj <[email protected]>
private TracingUtils(){} | ||
private static void assertGlobalTracerIsRegistered() { | ||
if (!GlobalTracer.isRegistered()) { | ||
throw new IllegalStateException("Please register a io.opentracing.util.GlobalTracer."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yurishkuro I felt it was simpler to use GlobalTracer.get()
directly in ActiveSpanSourceTraceContext
. It makes tests dirtier, but it's temporary code.
What is your opinion on the assertGlobalTracerIsRegistered
check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not pass it the GlobalTracer.INSTANCE as we discussed? By using GlobalTracer directly you're introducing tight coupling in the new class, which didn't need to happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The type of GlobalTracer.INSTANCE
is GlobalTracer
and I didn't see that as being particularly advantageous because it still couples ActiveSpanSourceTraceContext
to the implementation of GlobalTracer
.
Instance implements there Tracer interface, which decouples the new span from GlobalTracer dependency |
|
This reverts commit 55d04df. Signed-off-by: Prithvi Raj <[email protected]>
Signed-off-by: Prithvi Raj <[email protected]>
05dffa5
to
67bf0f4
Compare
Signed-off-by: Prithvi Raj <[email protected]>
Signed-off-by: Prithvi Raj <[email protected]>
@yurishkuro Coveralls diffs against the latest successful build on |
master build is green now. I restarted this build. |
Signed-off-by: Prithvi Raj <[email protected]>
Signed-off-by: Prithvi Raj <[email protected]>
ActiveSpanSource
for propagation instead ofThreadLocalTraceContext
Signed-off-by: Prithvi Raj [email protected]