Open carlosalberto opened 5 years ago
Who is supposed that method in which circumstances?
@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.
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).
So it seems we have some agreement on this - any opinion @objectiser @yurishkuro @CodingFabian ?
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.
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 https://github.com/opentracing-contrib/java-jaxrs/issues/109 could use this one.
Hey @CodingFabian Did the reason given above sounds right to you? Let me know ;)
@yurishkuro @opentracing/opentracing-java-maintainers Opinion on this?
Decided to take on being able to clear the current
Scope
, if any - this is done to prevent leakingScope
objects that were left around unintentionally.If merged, this could become part of the next iteration of https://github.com/opentracing/specification/pull/122 ;)
@yurishkuro @adriancole @felixbarny @tylerbenson