Allow clearing the current Scope. #313

carlosalberto · 2018-10-18T01:00:25Z

Decided to take on being able to clear the current Scope, if any - this is done to prevent leaking Scope objects that were left around unintentionally.

If merged, this could become part of the next iteration of opentracing/specification#122 ;)

@yurishkuro @adriancole @felixbarny @tylerbenson

coveralls · 2018-10-18T01:04:56Z

Coverage increased (+1.04%) to 76.225% when pulling e9868ee on carlosalberto:scope_manager_clear into ac3c666 on opentracing:v0.32.0.

sjoerdtalsma

I think this is something that is good to have.
When returning threads back to their pool, you want to be sure not to leave things 'dangling'.

This could also really help issues like opentracing-contrib/java-jaxrs#109 and opentracing-contrib/java-jaxrs#87

opentracing-util/src/main/java/io/opentracing/util/AutoFinishScopeManager.java

opentracing-util/src/main/java/io/opentracing/util/ThreadLocalScopeManager.java

tylerbenson · 2018-10-18T06:15:24Z

opentracing-api/src/main/java/io/opentracing/ScopeManager.java

+     * This method can be called to discard any previously leaked {@link Scope} objects
+     * that were unintentionally left active.
+     */
+    void clear();


Is there any difference in expected behavior between this calling

activate(null)

Some implementations may keep a stack of activated scopes. My understanding is that clear() would clear the whole stack and activate would push another element on the stack.

Not quite sure but clear() may have slightly different semantics depending on whether the ScopeManager maintains a stack of Scopes or only holds the currently active scope.

👍 My context manager -by default- maintains a stack.

Sorry for the OT, but I'm thinking about doing the same. What are your reasons for that? Is your context manager on GitHub?

Care to share (@sjoerdtalsma @felixbarny) about the benefits and tradeoffs with actively managing a stack vs a simple reference to the current which thus has reference to its' parent.

Since you ask: My context manager is 'pluggable' and has no real opinion on stacking or not. The default context uses a stack so you can easily change e.g. the current Locale just in a small piece of code and have everything else the way it was. Current supported contexts include MDC, Spring security context, Locale, originating ServletRequest, and OpenTracing Span. You can plug additional types via a ServiceLoader SPI.
For many situations, having a Closeable context that can be nested is the 'easiest' for users (as it returns things to the way they were). For OpenTracing Spans however, I just delegate to the configured ScopeManager.
More info: https://github.com/talsma-ict/context-propagation
For questions, feel free to ping me at gitter, always curious what others think.

@tylerbenson Sorry, just re-read your question (sorry for the late reply)

a simple reference to the current which thus has reference to its' parent

--> This forms what I meant by stack, it virtually forms a 'stack' of contexts this way (opposed to keeping only the current value)

Tradeoffs for stacking:
➕ Support nesting
➕ User experience: 'return things they way they were' / 'works as expected' in many cases
➖ Obviously a ~~bigger~~ chance of bigger memory leaks if open-close semantics are not correctly used.
➖ More memory consumption / garbage collecting

More memory consumption / garbage collecting

Not sure if that is true. The stack won't be collected unless the thread terminates.

I don't think this is a good idea. It is a hack, but a similar hack can be achieved by allowing a closure that clears a scope. ex passing a null tracecontext to the thing that scopes the active span

the benefit of passing null is you can still provide for "descoping that null" which is in easiest form returning a noop scope object when it was already null.

felixbarny · 2018-10-18T14:22:53Z

Who is supposed that method in which circumstances?

sjoerdtalsma · 2018-10-18T14:54:41Z

@felixbarny

Who is supposed that method in which circumstances?

I can imagine some servlet filter right before returning the thread to the pool. Or a custom job scheduler, -again- also before returning a worker thread to the pool. i.e. the one who controls threads, but may not control the correct activation / closing of current scopes of all called code.

sjoerdtalsma · 2018-10-18T14:58:03Z

Long time ago in the times of application servers and class loaders, I even went as far to create a list of all static ThreadLocal uses in our entire codebase (including libraries) and remove() all of them after each web request.
It was a hack, but it made several memory leaks disappear and gave us time to perform a more thorough analysis of the root cause(s).

carlosalberto · 2018-10-19T12:25:29Z

So it seems we have some agreement on this - any opinion @objectiser @yurishkuro @CodingFabian ?

CodingFabian · 2018-10-19T13:35:04Z

I do not fully understand the purpose. Is this a band aid that can be used whenever something unexpected happens? A util for libraries to clear up the mess a user might have created or something that has legitimate use by a user?
users could just decide to not commit a span or create a new one.

While this api is technically no problem, I wonder what the guidelines for users are. How is this api intended to be used by end users.

carlosalberto · 2018-10-19T14:02:37Z

Hey @CodingFabian

So this is more of a preventive use case, I'd say, and is not expected to be used by final users most of the time (same as ScopeManager.active()).

Quoting @sjoerdtalsma:

I can imagine some servlet filter right before returning the thread to the pool

And the issue around opentracing-contrib/java-jaxrs#109 could use this one.

Tests must be extended when the following PR is merged: opentracing/opentracing-java#313

carlosalberto · 2018-11-06T13:48:53Z

Hey @CodingFabian Did the reason given above sounds right to you? Let me know ;)

@yurishkuro @opentracing/opentracing-java-maintainers Opinion on this?

Tests must be extended when the following PR is merged: opentracing/opentracing-java#313 Signed-off-by: Sjoerd Talsma <[email protected]>

Allow clearing the currently active Scope.

18933ff

carlosalberto added the breaking_change Introduces a breaking change label Oct 18, 2018

sjoerdtalsma approved these changes Oct 18, 2018

View reviewed changes

opentracing-util/src/main/java/io/opentracing/util/AutoFinishScopeManager.java Show resolved Hide resolved

opentracing-util/src/main/java/io/opentracing/util/ThreadLocalScopeManager.java Show resolved Hide resolved

tylerbenson reviewed Oct 18, 2018

View reviewed changes

Add a note on ThreadLocal not calling remove() for the clear().

e9868ee

felixbarny approved these changes Oct 19, 2018

View reviewed changes

sjoerdtalsma added a commit to talsma-ict/context-propagation that referenced this pull request Oct 24, 2018

Add Clearable test for OpenTracing propagation

73ff552

Tests must be extended when the following PR is merged: opentracing/opentracing-java#313

This was referenced Oct 29, 2018

Make active span be ignored by default; used as parent span if configured opentracing-contrib/java-jaxrs#110

Merged

Spans/traces leak between requests if child spans not finished correctly opentracing-contrib/java-jaxrs#109

Closed

carlosalberto added the enhancement label Dec 7, 2018

ohbus approved these changes Jan 16, 2021

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow clearing the current Scope. #313

Allow clearing the current Scope. #313

carlosalberto commented Oct 18, 2018

coveralls commented Oct 18, 2018 •

edited

Loading

sjoerdtalsma left a comment

tylerbenson Oct 18, 2018

felixbarny Oct 18, 2018

sjoerdtalsma Oct 18, 2018 •

edited

Loading

felixbarny Oct 18, 2018

tylerbenson Oct 18, 2018

sjoerdtalsma Oct 18, 2018 •

edited

Loading

sjoerdtalsma Oct 18, 2018 •

edited

Loading

felixbarny Oct 18, 2018 •

edited

Loading

codefromthecrypt Nov 10, 2018

codefromthecrypt Nov 10, 2018

felixbarny commented Oct 18, 2018

sjoerdtalsma commented Oct 18, 2018

sjoerdtalsma commented Oct 18, 2018

carlosalberto commented Oct 19, 2018

CodingFabian commented Oct 19, 2018

carlosalberto commented Oct 19, 2018

carlosalberto commented Nov 6, 2018

Allow clearing the current Scope. #313

Are you sure you want to change the base?

Allow clearing the current Scope. #313

Conversation

carlosalberto commented Oct 18, 2018

coveralls commented Oct 18, 2018 • edited Loading

sjoerdtalsma left a comment

Choose a reason for hiding this comment

tylerbenson Oct 18, 2018

Choose a reason for hiding this comment

felixbarny Oct 18, 2018

Choose a reason for hiding this comment

sjoerdtalsma Oct 18, 2018 • edited Loading

Choose a reason for hiding this comment

felixbarny Oct 18, 2018

Choose a reason for hiding this comment

tylerbenson Oct 18, 2018

Choose a reason for hiding this comment

sjoerdtalsma Oct 18, 2018 • edited Loading

Choose a reason for hiding this comment

sjoerdtalsma Oct 18, 2018 • edited Loading

Choose a reason for hiding this comment

felixbarny Oct 18, 2018 • edited Loading

Choose a reason for hiding this comment

codefromthecrypt Nov 10, 2018

Choose a reason for hiding this comment

codefromthecrypt Nov 10, 2018

Choose a reason for hiding this comment

felixbarny commented Oct 18, 2018

sjoerdtalsma commented Oct 18, 2018

sjoerdtalsma commented Oct 18, 2018

carlosalberto commented Oct 19, 2018

CodingFabian commented Oct 19, 2018

carlosalberto commented Oct 19, 2018

carlosalberto commented Nov 6, 2018

coveralls commented Oct 18, 2018 •

edited

Loading

sjoerdtalsma Oct 18, 2018 •

edited

Loading

sjoerdtalsma Oct 18, 2018 •

edited

Loading

sjoerdtalsma Oct 18, 2018 •

edited

Loading

felixbarny Oct 18, 2018 •

edited

Loading