[
https://issues.apache.org/jira/browse/THRIFT-5814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz resolved THRIFT-5814.
------------------------------------------
Fix Version/s: 0.25.0
Resolution: Fixed
Resolving. The test no longer depends on sleeps to synchronise with the server.
{{TestNoHangDuringStopFromClientNoDataSendDuringAcceptLoop}} slept 10ms after
starting the server and again after dialing it, then asserted that {{Stop}}
took at least the stop timeout. {{Stop}} waits on the wait group
{{TSimpleServer}} fills in {{innerAccept}}, so whenever the accept and the
goroutine start did not fit inside those naps the group was still empty and
{{Stop}} returned early - which is the flake.
The test now closes a {{processing}} channel from the handler and waits on it,
so it proceeds when the server has actually taken the connection rather than
after a fixed nap. The client connection is also kept alive through
{{t.Cleanup}}, since it is what holds the processor in {{ReadMessageBegin}}.
PR #3811, merged as {{cd490de63}}.
_This comment was created with AI assistance._
> go: Flaky test TestNoHangDuringStopFromClientNoDataSendDuringAcceptLoop
> -----------------------------------------------------------------------
>
> Key: THRIFT-5814
> URL: https://issues.apache.org/jira/browse/THRIFT-5814
> Project: Thrift
> Issue Type: Task
> Components: Go - Library
> Affects Versions: 0.20.0
> Reporter: Yuxuan Wang
> Priority: Minor
> Fix For: 0.25.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently the
> [TestNoHangDuringStopFromClientNoDataSendDuringAcceptLoop|https://github.com/apache/thrift/blob/cb9ceada554f47aa5ebbedfe3984de0983cf0226/lib/go/thrift/simple_server_test.go#L164]
> test in go library can be flaky (fails at roughly 1-in-100 chance)
> What this test does is roughly:
> # Create a local server listening on a random local port (via localhost:0)
> # Create a tcp client that connects to the server (via net.Dial) but does
> nothing after established the connection (so to server's PoV this is an idle
> client)
> # Tries to shutdown the server
> # Verifies that the shutting down of the server took at least the configured
> timeout, before server forcefully close idle client connections
> Step 4 can occasionally (rarely) fail because the server shutdown much faster
> than expected. I did some digging, the reason seems to be that the
> client-server tcp connection is broken after established (killed by the os or
> something?)
> So we need to find a way to keep the connection until server kills it to fix
> the flakiness of this test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
