Transferring managed span stack from one thread to another

[objectiser]

As discussed opentracing/specification#23 (comment) in the ongoing in-process context propagation issue, there may be cases where the trace context must be passed from one thread to another completely (possibly as a 'snapshot'), not just supplying the reference to the current span.

There is currently the clear method which disassociates the LinkedManagedSpan from the thread, but no means of associating it with a new thread.

Any thoughts on how this could be done?

[sjoerdtalsma]

Good point. I hadn't considered this use-case but I can imagine there are situations where this is appropriate. In the current API there's not really a representation for a stack of spans, so I guess without introducing new API concepts or 'leaking' internal representation this would not be easy in the current SpanManager.

[sjoerdtalsma]

The main difficulty comes from the freedom the SpanManager offers (there is no need for a stack, that's 'incidentally' the way the DefaultSpanManager works).
The manager should be able to capture and reactivate its own internal representation accross threads...

[objectiser]

Possibly a simple snapshot mechanism for now?

[sjoerdtalsma]

The idea was that the ManagedSpan kind of was such a snapshot mechanism 😢 ..
Now the ManagedSpan current() factory method needs to behave different depending on your use-case, but extending the API to accommodate this would make no sense for implementations that don't even maintain a stack at all...
I see the problem, but don't see an obvious solution just yet unfortunately... open to suggestions 😉

[sjoerdtalsma]

Maybe ManagedSpan should be replaced by Snapshot, but the API needs to be 'told' somehow to push (or even replace??) the whole stack instead of a current span.
How would implementations that don't have stacks behave when given the request?
Should we add an extension interface StackAware or something that defines this additional method?
(really just dumping my ideas here..)

[sjoerdtalsma]

Mention @bhs so you can follow this issue and think about it with your own work in mind 😉

[objectiser]

@sjoerdtalsma agree there is no obvious solution.

I guess there is two separate cases - passing a reference to the current span (handled by activate(Span)) and transferring the complete trace context - but then need to make sure not referenced in multiple threads. Possibly have two new methods - detach() returning ManagedSpan (removing from current thread) and attach(ManagedSpan) - associates with new thread - method names obviously could be changed.

The distinction is based on the use case - activate(Span) is just used to enable the new execution context to reference the parent span in the old execution context - whereas detach/attach is used to transfer the complete trace context between execution contexts?

[objectiser]

So it shouldn't matter whether implemented as stack or not - just defines the different semantics required by the application.

[sjoerdtalsma]

I like the direction you're going with this, but am a little worried about comprehension by people.
The current 'paired' methods can already easily be misunderstood as witnessed in various discussions.
activate / deactivate were actually the result of the recent meeting in Berlin where people were using those terms consistently.

Introducing a second pair of methods for similar but different meaning may be too much.
I like your choices though: attach / detach in my mind implies something as 'glue this to the thread', which comes very close to what you try to do!

[objectiser]

Maybe the simplest solution then would be to add an activate(ManagedSpan) but only allow it to be used if the ManagedSpan is free from any other execution context - otherwise an exception could be thrown.

Then the issue is how to mark a ManagedSpan as being free - possibly an internal flag that would be set when the clear method is called?

[sjoerdtalsma]

We would have to be very clear what it means to activate a managed span (e.g. will any current span be cleared, or can it be restored later?) What will the difference between free / deactivated be?
We can try, but this may well become just as complicated as an additional pair of methods..
😓 ..

[objectiser]

Ok lets see if others have any suggestions.

[bhs]

FWIW, in opentracing/opentracing-java#111 I tried to push callers towards a try-with-resources idiom and a Span-aware Continuation concept. This felt like an easier way to encourage paired method invocations and has other benefits (e.g., dealing with Exceptions naturally).

[objectiser]

Hi @sjoerdtalsma , any thoughts on a way forward with this issue? Or would you prefer to leave and we get it sorted in opentracing-java?

[sjoerdtalsma]

Personally I lean towards:

• an alternate pair of methods
• defined in a separate extension interface (as it manages more than a Span)
• so only stack-based or otherwise complex SpanManager implementations need to implement it
  (for non-complex cases you can simply transfer the Span using current API)

My remaining concern is implementors 'forgetting' to implement that extension interface where applicable.
@objectiser Does this make any sense to you? 😉

[sjoerdtalsma]

@bhs

I tried to push callers towards a try-with-resources idiom and a Span-aware Continuation concept. This felt like an easier way to encourage paired method invocations

That's actually what ManagedSpan does too, but I made close() an explicit alias for deactivate() to be clear about its purpose.
By the way: I prefer your name Continuation over ManagedSpan.
(just maybe include Span somewhere to be clear about what is continued, given this issue which seems to be wanting for a continuation transfer of the entire stack) ?

[objectiser]

@sjoerdtalsma Yes that makes sense. Any idea when it could be available? :)