-
Notifications
You must be signed in to change notification settings - Fork 925
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
Make zipkin's current context can be nested #1262
Conversation
Apply this change will fix TraceContext leak in thread problem. There is a case that we keep armeria's request context aware CompletableFuture for fetching data, and let multiple request register callback on that future. So there is a problem that future uses first request's eventloop and RequestContext to call waiting handlers, but each handler may wrap with it's RequestContext, so there is nested RequestContext on same thread(onEnter->onEnter->onExit->onExit). Another solution is application developer should always jump back to current request's context aware eventloop. e.g. ``` cachedFuture.acceptAsync((r, e)->{ ... }, RequestContext.current.contextAwareEventloop); ``` I'm not sure if armeria side need to take care of this or not...
Codecov Report
@@ Coverage Diff @@
## master #1262 +/- ##
==========================================
- Coverage 72.64% 72.57% -0.07%
==========================================
Files 557 558 +1
Lines 24141 24156 +15
Branches 2943 2944 +1
==========================================
- Hits 17538 17532 -6
- Misses 5055 5073 +18
- Partials 1548 1551 +3
Continue to review full report at Codecov.
|
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.
Just some nits.
} | ||
|
||
@Nullable | ||
public SpanInScopeWrapper getPrevious() { |
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.
nit: previous()
?
import brave.Tracer.SpanInScope; | ||
|
||
/** | ||
* SpanInScope Wrapper for keeping previous span 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.
{@link SpanInScope} wrapper that keeps the previous {@link SpanInScope}.
Can you add test cases with the offending behavior? It'd also help document the affected case. |
I'm also sort of wondering what it means in terms of tracing to restore a parent context after a child context. Assuming
/cc @adriancole if you have any thoughts. |
Add test. So if we don't keep previous scope and restore, then there is a scope can't be close. Not sure the question, but I don't think there is a situation that client scope has another client scope ? |
protected void configure(ServerBuilder sb) throws Exception { | ||
|
||
final CountDownLatch countDownLatch = new CountDownLatch(2); | ||
final AtomicReference<CompletableFuture<HttpStatus>> cache = new AtomicReference<>(); |
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 use caffeine, so this is similar situation.
try { | ||
final RequestContext requestContext = RequestContext.current(); | ||
return HttpResponse.from( | ||
cache.get().thenApply(status -> { |
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.
Or the application dev must always know using thenApplyAsync
with current evetloop.
final RequestContext requestContext = RequestContext.current(); | ||
return HttpResponse.from( | ||
cache.get().thenApply(status -> { | ||
try (SafeCloseable ignored = RequestContext.push(requestContext)) { |
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 see, the example seems to have two unrelated server context's on the same request context stack. Is this allowed by the semantics of RequestContext
? We have features like RequestContext.onChild
, which I don't think support this sort of behavior, pushing a context here is like saying we're creating a new child context, so the unrelated "parent"'s onChildCallbacks
would run too from what I can tell.
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.
oops, right. Didn't notice about #onChild
.
Also do you think I should use propagateContextIfNotPresent
in here too? https://github.com/line/armeria/blob/master/rxjava/src/main/java/com/linecorp/armeria/common/rxjava/RequestContextCompletable.java#L38
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.
Yeah going with propagate if not present seems safer for that sort of callback, so while new contexts don't get set up properly, at least old contexts won't be affected poorly which I guess is usually better. Maybe some sort of logging could be added for such a case.
FWIW, the reason I added this comment a long time ago is because in my experience it's extremely difficult if not impossible to get "context" to work in asynchronous code in Java (which can only try mapping them to ThreadLocal
) without jumping threads. Perhaps we could call this out in the documentation better - wonder what others' thoughts are
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.
Thanks, it's so easy to forget using Async callback so thats why we want to use this kind of hook for chaining sync/async operations.
I will close this PR and try to make RxJava hook strictly.
Apply this change will fix TraceContext leak in thread problem.
There is a case that we keep armeria's request context aware CompletableFuture
for fetching data, and let multiple request register callback on that future.
So there is a problem that future uses first request's eventloop and RequestContext
to call waiting handlers, but each handler may wrap with it's RequestContext, so
there is nested RequestContext on same thread(onEnter->onEnter->onExit->onExit).
Another solution is application developer should always jump back to current request's
context aware eventloop. e.g.
I'm not sure if armeria side need to take care of this or not...