Can we define a shared thread-local storage format for Spans? about opentracing-java

[toaler]

We ended up creating a Span factory that provides static methods to create/destroy spans that set/remove the span from thread local. The factory also allows us to get the span in context on the corresponding thread (similar to TraceContext.getCurrentSpan()). Have not considered cross thread communication as of yet.

[yurishkuro]

cc @michaelsembwever @oibe

[yurishkuro]

Some prior art & discussions: DistributedTracing/continuation-local-storage-jvm#1

[jmacd]

@bensigelman What you posted looks good, but I recall Google didn't promote the use of wrapped Runnable objects as much as it promoted the use of a new threads for each span, so there was effectively not a stack. The RPC client never had to swap the span because it blocked, and the server never had to swap the span because it created or re-used a thread. e.g.,

  new TraceContextThread(SpanBuilder.SetOperation(...).
      StartSpan(TraceContext.getCurrentSpan() /* i.e., parent */), new Runnable() {
    public void run() { ... }
  }).start();

[yurishkuro]

@toaler can you point to or paste some code examples? From your description of the "factory" it seems it had a much richer API than needed purely for propagating span via TLS. We wouldn't want to replicate OT API for spans in another class.

[sjoerdtalsma]

What do you think of the following approach?

I'm in the process of releasing a 'context-propagation' library where I abstracted the 'Context' concept and created a Service interface for ContextManager and a utility-class ContextManagers that allows taking a snapshot of 'all' compatible Context implementations.
This snapshot can be 'reactivated' in another thread, returning an AutoCloseable instance, restoring the state after use.
An abstract ThreadLocal based context implementation is provided that effectively restores the state in a stack-like fashion when closed.
Having your own Context implementation cooperate in the propagation only requires declaring your ContextManager's classname in a META-INF/services property file.

https://github.com/talsma-ict/context-propagation

I would be willing to provide an implementation in 'contrib' that uses this construct to manage spans with implicit context, using delegation to existing Tracer implementations..

[yurishkuro]

fyi, larger discussion here: opentracing/specification#23

[bhs]

also see #115...

[bhs]

(Closed by #115)