`TracingServerInterceptor` not closing activated `Scope`s ?

[jelgh]

Hey,

We're having java services OOMing and traced the leakage to be related to a non-closed Scope returned from tracer.scopeManager().activate(span).

We fixed those issues and now see OOMs from another service where we don't have the above bug in our code. However, we use the TracingServerInterceptor from this library, and I noticed now that this class does does close the activated Scopes.

From the javadoc of io.opentracing.Tracer you find:

    /**
     * Make a {@link Span} instance active for the current context (usually a thread).
     * This is a shorthand for {@code Tracer.scopeManager().activate(span)}.
     *
     * @return a {@link Scope} instance to control the end of the active period for the {@link Span}. It is a
     * programming error to neglect to call {@link Scope#close()} on the returned instance,
     * and it may lead to memory leaks as the {@link Scope} may remain in the thread-local stack.
     */
    Scope activateSpan(Span span);

Am i missing anything or is there a bug in the code here? Happy to be proven wrong! 😄

[jelgh]

This also exists in the client one TracingClientInterceptor btw

[zzxgzgz]

Hi,

Is there any update on this one? I think I am encountering the same problem here.

I'm using a TracingServerInterceptor to trace my gRPC server, and it seems like that the server spans are not closing, which is producing a trace graph like this:

The RequestGoalStates are separate, but the later spans are generated as if they are the children of the previous span.

Am I using the interceptor incorrectly? Any help will be appreciated.

Thank you,
Rio