-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
x/net/http2: RoundTrip and/or CloseIdleConnections may leave connections in use after returning #50027
Comments
Change https://golang.org/cl/369936 mentions this issue: |
"Closing" a connection marks the connection as closed (sets So after Perhaps closing a connection should block until the connection goroutines have all returned. |
It would be great if CloseIdleConnections waited for all goroutines to have returned. Right now, after an error in a http.Client.Do, closing idle connections results in at least 1 goroutine leaked:
|
In #43176, we observed that
x/net/http2.TestTransportGroupsPendingDials
sometimes fails on various platforms.The test performs multiple concurrent calls to a
Transport
'sRoundTrip
method, waits for them to return, closes theResponse
bodies, and then callsCloseIdleConnections
. If all of those functions are synchronous — their signatures suggest that they should be, and nothing in their documentation states otherwise — then theTransport
's client connection pool should be empty as soon as that sequence is complete.However, the connection pool is empirically not empty at that point, and to my knowledge never has been. The test has had a
retry
loop ever since it was added (in CL 17134), and even then a single call toCloseIdleConnections
before the retry loop is empirically not enough to ensure that it succeeds.We should add more explicit tests for the expected invariants after
RoundTrip
andCloseIdleConnections
, and/or update the documentation for those methods (and the corresponding methods and interfaces in thenet/http
package) to make those invariants clearer for end users, who may want to make use of any such invariants in their own tests.(CC @neild @tombergan @bradfitz)
The text was updated successfully, but these errors were encountered: