tweaks to ckozak's DetachedSpan & demo usage - #247
Conversation
Generate changelog in
|
| : Tracer.createTrace(Observability.UNDECIDED, Tracers.randomId()); | ||
|
|
||
| Optional<String> parentSpanId = trace.top().map(OpenSpan::getSpanId); | ||
| OpenSpan openSpan1 = OpenSpan.of( |
|
|
||
| Map<String, String> metadata = Collections.emptyMap(); | ||
| Span span = Tracer.toSpan(inProgress, metadata, traceId); | ||
| Tracer.notifyObservers(span); |
There was a problem hiding this comment.
it'd be nice to pull lines 85-89 and 70-76 into a common private function
|
|
||
| // we throw away the existing thread local state and replace it with our view of the world | ||
| Tracer.clearCurrentTrace(); | ||
| Tracer.setTrace(Trace.of(observable, traceId)); |
There was a problem hiding this comment.
I think maybe I'd wrap up the clearCurrentTrace+setTrace into a couple a private method replaceTraceState that takes no args, you can reuse it in child, too
| } | ||
|
|
||
| /** | ||
| * Unusual method - returns a new {@link CrossThreadSpan} parented to this instance. Only necessary if you want |
There was a problem hiding this comment.
would be helpful to include an example in the docs of when to use this, it's not obvious how to select child or this method, both result in a parented CrossThreadSpan?
|
@jellis curious if this works for your needs? |
…o dfox/cross-thread-tracing
iamdanfox
changed the title
|
Ok so this is just gonna land into the existing DetachedSpan branch - I think it will let us do all the tracing we want in c-j-r. Hope the names look OK from your perspective @carterkozak? Definitely still want to explore Mark's new internal representation ideas, but don't want to block this PR on that (as it should be easy to polyfill later if we need to). |
| * Closeable marker around a tracing span operation. This object should be used in a try/with block. | ||
| */ | ||
| public interface SpanToken extends Closeable { | ||
| public interface CloseableSpan extends Closeable { |
|
👍 |
1 similar comment
|
👍 |
4 participants
Before this PR
In conjure-java-runtime and dialogue, we want to be able to measure a span of time beginning on one thread and ending on another (e.g. backoffs or client-side concurrency limits). We do have an
AsyncTracerclass already, but this makes two spans:<operation>-enqueueand<operation>-run.After this PR
A newCrossThreadSpanclass allows measuring operations that begin on one thread and end on another.I'm not expecting this to be used by regular service authors much, but hoping we can benefit from it in our libraries.Possible downsides?
TODO