-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds BaggageThreadLocalAccessor #508
Conversation
previously we've tried to store both baggage and span through TracingObservationHandler. That didn't hold when working with reactive applications because it would require users to create artificial baggage scopes and actually due to scopes getting closed early, we would lose the actual baggage value on the attached TraceContext. with this change we revert to previous approach where the TOH actually creates a scope for spans only. For context propagation we are treating baggage as a first class citizen that requires its own ThreadLocalAccessor, that's why we create the BaggageThreadLocalAccessor, that should be registered after the ObservationAwareSpanThreadLocalAccessor. With that, in reactive applications, under the BaggageThreadLocalAccessor#KEY users will need to register the BaggageToPropagate in e.g. Reactor Context and then it's up to the Context Propagation library to start and stop scopes. Additional tasks: * BraveBaggageManager can have the Micrometer Tracer set on it ** BraveTracer automatically sets itself on BBM ** Current Span will now be resolved from the MT if possible
e349988
to
5bee69f
Compare
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'm a bit blurry on the situation where traceContext
is empty for BaggageInScope
, so I just expressed this in some questions. In general this effort looks good, time to add some tests :) Also, are there no changes required in the OTEL counterpart?
@@ -214,6 +179,9 @@ public void restore(Span previousValue) { | |||
|
|||
@Override | |||
public void restore() { | |||
if (log.isTraceEnabled()) { | |||
log.trace("Restoring no args"); |
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.
Consider "restoring to empty span scope"
@@ -226,21 +194,26 @@ static class SpanAction implements Closeable { | |||
|
|||
final Map<Thread, SpanAction> todo; | |||
|
|||
Consumer<?> scope; | |||
Closeable scope; |
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 there any arguments against using AutoCloseable
instead?
...meter-tracing/src/main/java/io/micrometer/tracing/contextpropagation/BaggageToPropagate.java
Show resolved
Hide resolved
private final Map<String, String> baggage; | ||
|
||
public BaggageToPropagate(Map<String, String> baggage) { | ||
this.baggage = baggage; |
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.
Should this be a reference assignment or a copy? Please see my other comment in BaggageThreadLocalAccessor
.
log.trace("Current baggage in thread local [" + baggageInScope.get(Thread.currentThread()) | ||
+ "], current baggage from tracer [" + baggage + "]"); | ||
} | ||
return (baggage == null || baggage.isEmpty()) ? null : new BaggageToPropagate(baggage); |
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'm a bit concerned about the isEmpty()
check. I can imagine a situation where even though the map is empty, it can be filled in later, which won't be reflected. That sounds ok, but at the same time, currently, a non-empty map can become empty later and with a reference used will make the contents be reflected in the captured BaggageToPropagate
. This should be consistent. Most probably by just copying the contents in the constructor of the holder.
|
||
@Override | ||
public void setValue(BaggageToPropagate value) { | ||
BaggageAndScope previousConsumer = baggageInScope.get(Thread.currentThread()); |
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 is the name consumer used here?
public void setValue() { | ||
BaggageAndScope previousConsumer = baggageInScope.get(Thread.currentThread()); | ||
if (log.isTraceEnabled()) { | ||
log.trace("setValue no args, current baggage scope [" + baggageInScope.get(Thread.currentThread()) + "]"); |
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.
Consider "setValue to empty baggage scope ..."
@Override | ||
public void restore() { | ||
if (log.isTraceEnabled()) { | ||
log.trace("Calling restore()"); |
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.
Consider "restoring to empty baggage scope"
@@ -44,6 +44,9 @@ public BraveTracer(brave.Tracer tracer, CurrentTraceContext context, BaggageMana | |||
this.tracer = tracer; | |||
this.braveBaggageManager = braveBaggageManager; | |||
this.currentTraceContext = context; | |||
if (braveBaggageManager instanceof BraveBaggageManager) { |
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.
If it's not a BraveBaggageManager, isn't it an error? Should the previous assignment still be executed?
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.
Theoretically a user can provide their own baggage manager. Practically there are almost zero chances that this would happen
this.delegate.updateValue(value); | ||
boolean success = this.delegate.updateValue(value); | ||
if (logger.isTraceEnabled()) { | ||
logger.trace("Managed to update the baggage on set [" + success + "]"); |
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.
Would it be beneficial to distinguish the log from the situation where a traceContext
is present?
ef4d9fc
to
967ca1b
Compare
967ca1b
to
8ff705e
Compare
previously we've tried to store both baggage and span through TracingObservationHandler. That didn't hold when working with reactive applications because it would require users to create artificial baggage scopes and actually due to scopes getting closed early, we would lose the actual baggage value on the attached TraceContext.
with this change we revert to previous approach where the TOH actually creates a scope for spans only. For context propagation we are treating baggage as a first class citizen that requires its own ThreadLocalAccessor, that's why we create the BaggageThreadLocalAccessor, that should be registered after the ObservationAwareSpanThreadLocalAccessor. With that, in reactive applications, under the BaggageThreadLocalAccessor#KEY users will need to register the BaggageToPropagate in e.g. Reactor Context and then it's up to the Context Propagation library to start and stop scopes.
Additional tasks:
Related issue - #504
Usage example