Context Propagation

[carlosalberto]

I'm creating this issue to provide initial insight into the Context propagation design.

OT Tracers with custom propagation

One of the important questions has been what kind of custom propagation is done by Tracers. I reviewed DataDog. This is a simplified list of their extra needs:

• Need to provide events around Span operations (events after a Span has been activated or after it has been closed, for example).
• Need to do extra checks in order to either close or not the Span upon Scope being closed (similarly to how we do it for the ref-counting ScopeManager in opentracing-util). This checks are done on the actual Span underneath and its internal features.
• Stores a list of extra Context objects, which can be queried besides the TLS storage.
• Uses an actual Deque for storing the Scope objects (opposed to how this is done in OC/OT).

Tracers with bridges to OT

I reviewed Brave-Opentracing and found out it uses its very own context propagation layer. This one in turn is similar to the OC one, including the storage of the propagation layer exposed as a SPI component, in case the users wants to override it.

I quote the original feedback from Elastic, which also offers OT support as a bridge layer:

They have an existing context propagation mechanism in place, which doesn’t implement the OT interfaces, and hence bridges are built. This propagation mechanism is leveraged for their auto instrumentation mode too, and it co-exists with the manual mode (“mix and match mode” is called).

If Scope objects are created by an in-place propagation mechanism, they would be detached from the ones the auto agent creates.

Implementation wise, they use thread-local data, but they don’t use an implicit stack of Scope objects, but an explicit one (it keeps all the previously active Scope objects).

[tylerbenson]

@carlosalberto Thanks for the review. I'd like to clarify something...

I don't think the added complexity of what we have currently implemented is needed and we should stick to a simple thread local based context.

I originally implemented it the way you described to support using a custom context with frameworks that have a static context like Ratpack. The idea being a thread local context would be used unless on a particular thread managed by a different context.

In practice, Ratpack seems to be the only framework I've come across where this is useful and I think the complexity in the core should be instead shifted to complexity in the instrumentation.

That said, I appreciate you considering our needs and asking for feedback. Happy to answer further questions.

[tylerbenson]

I'd like to add... I think it would be valuable to add one thing to the OT scope api and that is a listener... something that can be used for things like MDC support.

[yurishkuro]

We're talking about in-process propagation only here, correct? Maybe change the title accordingly.

[carlosalberto]

@yurishkuro IIRC Bogdan doesn't like the term "in-process" ;)

[carlosalberto]

@tylerbenson You mean an event listener layer?

[tylerbenson]

Yeah. A way to receive callbacks when a span and scope starts and stops.

[carlosalberto]

For reference, we are currently discussing this item in https://docs.google.com/document/d/1B9TDx1-ynlpD2IzYVUjIqN-ImV1Uu9_mfw0fT37rJyo/edit?usp=sharing ;)