-
Notifications
You must be signed in to change notification settings - Fork 19
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
[fix] Open a new span when wrapping with a new trace #49
Conversation
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.
lgtm
return delegate.call(); | ||
} finally { | ||
Tracer.completeSpan(); |
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.
fastCompleteSpan?
delegate.run(); | ||
} finally { | ||
Tracer.completeSpan(); |
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.
fastCompleteSpan
@@ -148,8 +149,10 @@ public static ScheduledExecutorService wrapWithNewTrace(ScheduledExecutorService | |||
|
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.
Looks like there's an existing bug where wrapping a callable will leave an empty trace with no root span on the thread if there's not already an active trace.
Tracer.getAndClearTrace
should probably return Optional<Trace>
Not related to this change though.
API rev isn't required for this change, but I don't think it solves the linked ticket. This definitely fixes a bug (thanks!), but it's still possible to invoke |
…new trace (#59) ## Before this PR When calling any of the `wrapWithNewTrace` methods, the operation of the initial span would be set to "root". This makes it difficult to determine the origin of traces if `wrapWithNewTrace` is used in more than one place. ## After this PR `Tracers` now provides variants of the `wrapWithNewTrace` methods that allow callers to explicitly set the initial span operation. Follow up to #49.
Before this PR
Creating a new trace does not create a new root span. Thus all top-level calls in this trace will have no parent span. This breaks assumptions of trace log consumers who assume that there is only one root span for a given trace.
This also seems counter to the
parentId
specification in the Zipkin API:After this PR
Creating a new trace will create a new root span.
The issue is part of the
Major API revision
milestone, but this fix does not break the API. Is a major API revision required for this change?