Maybe memory leak in Netty 4 transport.

[He-Pin]

refs:

OOM reported: https://issues.apache.org/jira/browse/FLINK-36290

https://issues.apache.org/jira/browse/FLINK-36510
I think there will be some leak, eg, not calling ByteBuf.release somewhere.

Update:
The current code is right.

I think the only way to find where it leaked is using -Dio.netty.leakDetection.level=PARANOID and return the test,
Or they can rerun the tests with -Dio.netty.tryReflectionSetAccessible=true.

[pjfanning]

The link makes no mention of Pekko. Can you remove the labels (bug and backport) until there is Pekko specific POC for this?

[pjfanning]

We now have #1635 but can we take a little bit of time and care. There is no point rushing this. The change is not really usable until we do a release. Can we slow down the effort and stop opening multiple PRs at the same time?

[pjfanning]

@He-Pin you linked https://issues.apache.org/jira/browse/FLINK-36788 - I don't understand why. The real issue appears to be https://issues.apache.org/jira/browse/FLINK-36510

[He-Pin]

@pjfanning Sorry,I wrong linked , have updated to the right link

[He-Pin]

Actually, the code is Right:(,

Because it extends the SimpleChannelInboundHandler which will do auto-release.

finally {
            if (autoRelease && release) {
                ReferenceCountUtil.release(msg);
            }
        }

[He-Pin]

Do local run with cluster/MultiJvm/test and -Dio.netty.leakDetection.level=PARANOID to find if it leaked.

[pjfanning]

Isn't it good that there is no leak?

Can we close this?

Any ideas what might be going wrong in Flink tests? https://issues.apache.org/jira/browse/FLINK-36290

Do we need the exception handling changes that you were trying to make in #1635 ?

[He-Pin]

Yes, I run it locally, and no leak, otherwise it will prints something like:

LEAK: {}.release() was not called before it's garbage-collected.

[He-Pin]

@pjfanning I think the exception handing is nice, I will add it in another PR.
Iet's close it after #1639 merged and checked it again.

[He-Pin]

@pjfanning I think the only way to find where it leaked is using -Dio.netty.leakDetection.level=PARANOID and return the test, which will print the detailed leaked position.

Or they can rerun the tests with -Dio.netty.tryReflectionSetAccessible=true.

The issue seems only on Java 11+, so maybe try with -Dio.netty.tryReflectionSetAccessible=true.