Skip to content

netty: netty tests resource leakage issue #11593

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

Merged
merged 45 commits into from
Dec 2, 2024

Conversation

vinodhabib
Copy link
Contributor

@vinodhabib vinodhabib commented Oct 3, 2024

I can see there are multiple tests in netty server and client side are randomly failing with resource leakage error and this PR will be fixing some of them at Server and Client side as below.

Note : Made some common method changes (as per Eric Suggestion/Reference) in all 3 tests files and currently tests which are shown below in Pending Server Base are one which are majorly impacting in both Server and Client test randomly which has common root cause while invoking the dataFrame() which we discussed earlier and tried suggestion as shown in the comment
#3353 (comment)

Server Side UTs Fixes:
sendFrameShouldSucceed()
inboundDataWithEndStreamShouldForwardToStreamListener()
inboundDataShouldForwardToStreamListener()
keepAliveEnforcer_sendingDataResetsCounters()
maxRstCount_withinLimit_succeeds()
maxRstCount_exceedsLimit_fails()

NettyHandlerTestBase.dataSizeSincePingAccumulates()

Client Side UTs Fixes
sendFrameShouldSucceed()

Pending UTs at Server Base
NettyHandlerTestBase.bdpPingWindowResizing
NettyHandlerTestBase.bdpPingLimitOutstanding
NettyHandlerTestBase.windowUpdateMatchesTarget
NettyHandlerTestBase.testPingBackoff

Note : you can refer the comment #3353 (comment) for more details on these 4 pending Server Base UTs behavior

Fixes #3353

# Conflicts:
#	netty/src/test/java/io/grpc/netty/NettyHandlerTestBase.java
@vinodhabib vinodhabib changed the title Defect 3353 - netty tests resource leak fix netty - netty tests resource leakage issue Oct 4, 2024
@vinodhabib vinodhabib changed the title netty - netty tests resource leakage issue netty: netty tests resource leakage issue Oct 4, 2024
…stenerMessageQueue in NettyServerTests as it's not working as expected
@vinodhabib vinodhabib changed the title netty: netty tests resource leakage issue grpc-netty: netty tests resource leakage issue Oct 14, 2024
@kannanjgithub kannanjgithub added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Nov 11, 2024
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Nov 11, 2024
@@ -1315,7 +1313,9 @@ private void rapidReset(int burstSize) throws Exception {
for (int period = 0; period < 3; period++) {
for (int i = 0; i < burstSize; i++) {
channelRead(headersFrame(streamId, headers));
channel().releaseOutbound();
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need both releaseOutbound()s?

Copy link
Contributor Author

@vinodhabib vinodhabib Nov 12, 2024

Choose a reason for hiding this comment

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

I have added these releaseOutbounds() here as i saw leakage error in the below 2 UTs which are calling the rapidReset() method and it has outbound messages which are not released.

maxRstCount_withinLimit_succeeds()
maxRstCount_exceedsLimit_fails()

Copy link
Member

Choose a reason for hiding this comment

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

releaseOutbound() is the sort of thing that only needs to be run once at the end of tests, to avoid leaks. Running it at the end of @Before could be okay if we don't want tests to see any queued messages, but there's no point to calling it multiple times here. Really, I'm surprised it isn't placed mostly just once in an @After to clean up after every test.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

Copy link
Contributor

Choose a reason for hiding this comment

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

I had allowed that based on this existing call inside a loop, which gave me the impression that the queue might be getting emptied without releasing and refilled multiple times during the test but that is not the case.

@@ -1346,7 +1368,7 @@ private ByteBuf emptyGrpcFrame(int streamId, boolean endStream) throws Exception
try {
return dataFrame(streamId, endStream, buf);
} finally {
buf.release();
buf.clear();
Copy link
Member

Choose a reason for hiding this comment

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

I agree the release() looks like it should go away (the ownership is being transferred to dataFrame(), but clear() is useless here. Just delete the line?

@ejona86 ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Nov 12, 2024
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Nov 12, 2024
@vinodhabib vinodhabib requested a review from ejona86 December 2, 2024 09:41
@ejona86 ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Dec 2, 2024
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Dec 2, 2024
@ejona86 ejona86 merged commit f66d7fc into grpc:master Dec 2, 2024
15 checks passed
larry-safran pushed a commit to larry-safran/grpc-java that referenced this pull request Dec 6, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 3, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Resource leak in netty tests
4 participants