scopeManager#activate creates new scope every time it's called

For me, it was intuitive that if I activate a span that is already active then nothing happens. Turns out, I leak Scope instances if I do that.

Span span = ...
Scope scope1 = tracer.scopeManager().activate(span);
Scope scope2 = tracer.scopeManager().activate(span);
Scope scope3 = tracer.scopeManager().activate(span);

Would be great if scope1, scope2, and scope3 would be the same Scope instance. It is bit more code for the library but it is also a bit more user-friendly.

Found out about it in https://github.com/AxonFramework/extension-tracing/pull/17

[whiskeysierra]

It’s more robust if you activate the same Span twice and get the same Scope instance activated than having 2 Scopes for this Span.

No, it’s not. Here is why:

(L1 and L2 are two different layers in your application, e.g. two classes and L1 calls L2.)

1. L1: Activate span
2. L2: Activate span
3. L2: Close scope
4. L1: Close scope

The scope is closed after 3. Now in L1 before step 4, the layer has a reasonable expectation that the span that it activated is still active, but it no longer is. 💥

What you’re trying is to introduce an unnecessary entangling of span lifecycle (start + finish) and scope management (activate + close). Those two are orthogonal concerns and are better be kept apart. You can see this reflected in the most recent API versions because all methods that couple both concepts together are now removed:

• startActive()
• .activate(span, closeOnFinish)

Whether you create a new span or use the currently active span is independent of whether you activate this span afterwards. If you couple them you’d violate the Principle of Least Knowledge because suddenly your inner layers need to know whether it’s safe to close the scopes that they obtain.

Now, when you keep those two things apart, as they are now you don’t have any of those problems. Every layer can choose to activate a span or not without the need to know about the outer/upper layer and without the fear of breaking anyone.

[whiskeysierra]

Seems like we could “detect” the currently active span without the concept of Scope

The thread local approach doesn’t work for reactive, non-blocking applications that work with an event loop.