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

Update Netty 4.1.114 -> 4.1.115 #3097

Merged
merged 2 commits into from
Nov 13, 2024
Merged

Conversation

idelpivnitskiy
Copy link
Member

No description provided.

@@ -390,6 +390,8 @@ void serverCloseTwoPipelinedRequestsSentBeforeFirstResponse(boolean useUds, bool
@MethodSource("io.servicetalk.http.netty.ConnectionCloseHeaderHandlingTest#pipelinedRequestsTestData")
void serverCloseSecondPipelinedRequestWriteAborted(boolean useUds, boolean viaProxy,
boolean awaitRequestPayload) throws Exception {
assumeFalse(viaProxy, "Let all other tests run with Netty 4.1.115");
Copy link
Member Author

Choose a reason for hiding this comment

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

Heads up that I had to disable this test to proceed and let benchmarks run with newer Netty

@idelpivnitskiy idelpivnitskiy merged commit 9bf91c4 into apple:main Nov 13, 2024
11 checks passed
@idelpivnitskiy idelpivnitskiy deleted the netty115 branch November 13, 2024 04:07
idelpivnitskiy added a commit to idelpivnitskiy/servicetalk that referenced this pull request Nov 13, 2024
idelpivnitskiy added a commit to idelpivnitskiy/servicetalk that referenced this pull request Nov 13, 2024
idelpivnitskiy added a commit that referenced this pull request Nov 14, 2024
…3102)

Motivation:

Behavior of `SslHandler` in Netty 4.1.115 changed. Now it can wrap data and flush them to the network even if flush was not requested. In result, it affected our test `ConnectionCloseHeaderHandlingTest.PipelinedRequestsTest.serverCloseSecondPipelinedRequestWriteAborted` that we had to disable in #3097 to proceed with the upgrade.
Debugging showed that when we receive `AbortWritesEvent`, the following behavior of `WriteStreamSubscriber` depends on how many `activeWrites` we have. With 4.1.115 netty will flush data, there will be 0 `activeWrites` and it will close (with reset) the outbound. In result, we lose data of the previous response in the pipeline that we haven't read yet.

Modifications:
- Use `listenerDiscard` instead of `channelClosed` that will make sure new writes will be discarded without prematurely affecting the connection state regardless of the `activeWrites` count.
- Unskip the test.

Result:

Graceful handling of `connection: close` header does not depend on flushing behavior.
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.

1 participant