Skip to content

Auto-port 4.1: Avoid TCPFastOpen in KQueueCompositeBufferGatheringWriteTest#16699

Merged
normanmaurer merged 1 commit into
4.1from
auto-port-pr-16697-to-4.1
Apr 24, 2026
Merged

Auto-port 4.1: Avoid TCPFastOpen in KQueueCompositeBufferGatheringWriteTest#16699
normanmaurer merged 1 commit into
4.1from
auto-port-pr-16697-to-4.1

Conversation

@netty-project-bot
Copy link
Copy Markdown
Contributor

Auto-port of #16697 to 4.1
Cherry-picked commit: 38f7a73


Motivation:
We have seen occasional failures from this test in CI, like:

Error:  io.netty.channel.kqueue.KQueueCompositeBufferGatheringWriteTest.testSingleCompositeBufferWrite(TestInfo) -- Time elapsed: 0.045 s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <20> but was: <0>
	at io.netty.testsuite.transport.socket.CompositeBufferGatheringWriteTest$3$1.channelInactive(CompositeBufferGatheringWriteTest.java:109)

In the test, the server writes a composite buffer with 20 bytes as soon as a client connects, and the write future has a listener that closes the channel. I speculate that maybe the close races ahead of the write, when TFO is enabled. Normally, the kernel should still drain the send buffer of closed sockets, but maybe there's an interaction with TFO there.

Modification:
Disable the use of TFO in KQueueCompositeBufferGatheringWriteTest, which matches its epoll counterpart. Log warnings if an unusual IOException gets thrown on the client.

Result:
Maybe more stable test.

Motivation:
We have seen occasional failures from this test in CI, like:

```
Error:  io.netty.channel.kqueue.KQueueCompositeBufferGatheringWriteTest.testSingleCompositeBufferWrite(TestInfo) -- Time elapsed: 0.045 s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <20> but was: <0>
	at io.netty.testsuite.transport.socket.CompositeBufferGatheringWriteTest$3$1.channelInactive(CompositeBufferGatheringWriteTest.java:109)
```

In the test, the server writes a composite buffer with 20 bytes as soon
as a client connects, and the write future has a listener that closes
the channel. I speculate that maybe the close races ahead of the write,
when TFO is enabled. Normally, the kernel should still drain the send
buffer of closed sockets, but maybe there's an interaction with TFO
there.

Modification:
Disable the use of TFO in KQueueCompositeBufferGatheringWriteTest, which
matches its epoll counterpart. Log warnings if an unusual IOException
gets thrown on the client.

Result:
Maybe more stable test.

(cherry picked from commit 38f7a73)
@normanmaurer normanmaurer merged commit a169ebb into 4.1 Apr 24, 2026
17 of 18 checks passed
@normanmaurer normanmaurer added this to the 4.1.133.Final milestone Apr 24, 2026
@normanmaurer normanmaurer deleted the auto-port-pr-16697-to-4.1 branch April 24, 2026 14:09
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.

3 participants