Skip to content

Fix netty 4.1 instrumentation not removing future listeners#2851

Merged
laurit merged 3 commits into
open-telemetry:mainfrom
mateuszrzeszutek:netty-mem-leak
Apr 27, 2021
Merged

Fix netty 4.1 instrumentation not removing future listeners#2851
laurit merged 3 commits into
open-telemetry:mainfrom
mateuszrzeszutek:netty-mem-leak

Conversation

@mateuszrzeszutek

Copy link
Copy Markdown
Member

Resolves #2705

public final class WrappedFutureListener<F extends Future<? super Void>>
implements GenericFutureListener<F> {

private static final Cache<GenericFutureListener<?>, WrappedFutureListener<?>> wrappers =

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like it can be InstrumentationContext instead of a map right?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I thought about it too - I don't know how it'd work with lambdas or method references, and how costly adding a field to lots of listener classes would be. (It's a good idea for a benchmark though)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But isn't the weakmap a subset of InstrumentationContext? We use weakmap behind the scenes when not being able to add a field, and I figure when we can add the field it should basically work better.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One problem with InstrumentationContext is that it is incapable of handling cases when the same object is used in different contexts e.g. same runnable is submitted to executor multiple times. With wrappers it should be possible to handle such cases, though the current solution doesn't.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, changed to InstrumentationContext.

One problem with InstrumentationContext is that it is incapable of handling cases when the same object is used in different contexts e.g. same runnable is submitted to executor multiple times.

Hmm, I guess that it's a separate InstrumentationContext problem that applies to the whole javaagent. We'd probably like to get it solved separately.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One problem with InstrumentationContext is that it is incapable of handling cases when the same object is used in different contexts e.g. same runnable is submitted to executor multiple times.

Oh, that's an interesting problem, hadn't thought about that... have you seen this cause issues in real world apps (yet)?

@laurit laurit merged commit 77f8be8 into open-telemetry:main Apr 27, 2021
@mateuszrzeszutek mateuszrzeszutek deleted the netty-mem-leak branch April 27, 2021 08:24
schmikei pushed a commit to schmikei/opentelemetry-java-instrumentation that referenced this pull request Apr 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Netty instrumentation causes memory leak and more

4 participants