Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggests to dispose connection when cancelled In NettyWriteResponseFilter #3611

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

raccoonback
Copy link

@raccoonback raccoonback commented Dec 2, 2024

Hello.
I use spring-gateway, reactor-netty to operate the service.
While investing "LEAK: ByteBuf.release() was not called before it's garbage-collected", I would like to ask for suggestions on fixing NettyWriteResponseFilter.

NettyWriteResponseFilter disposes only when the connection channel is active.

However, it seems that FluxReceive may result in unreleased memory references. (ChannelOperations)
Therefore, I suggest modifying the configuration to always dispose of the connection regardless of the channel status.
(I understand that there is no redundant processing for dispose already inside the connection.)

image

For example, suppose that an incoming HTTP request was canceled while routing and responding.
Even though the NioSocketChannel channel is not active, a memory reference may remain in receiverQueue maintained in FluxReceive.

Actually, if delay 5 seconds with a custom GlobalFilter and generate a large number of HTTP cancels after 2 seconds of the total request time, "LEAK: ByteBuf.release() was not called before it's garbage-collected" occurred.

@violetagg
hello.
What do you think about this?

@raccoonback
Copy link
Author

Additionally, I have also reflect the feedback from this review.

@raccoonback raccoonback force-pushed the dispose-connection-when-cancelled branch from 6a4a5c2 to a08c8d7 Compare December 2, 2024 16:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants