net/http: Transport leaks context.Contexts when limited by MaxConnsPerHost #33850
Comments
Change https://golang.org/cl/191964 mentions this issue: |
Change https://golang.org/cl/191967 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Aug 27, 2019
…ransport I'm trying to keep the code changes minimal for backporting to Go 1.13, so it is still possible for a handful of entries to leak, but the leaks are now O(1) instead of O(N) in the steady state. Longer-term, I think it would be a good idea to coalesce idleMu with connsPerHostMu and clear entries out of both queues as soon as their goroutines are done waiting. Cherry-picked from CL 191964. Updates #33849 Updates #33850 Fixes #33878 Change-Id: Ia66bc64671eb1014369f2d3a01debfc023b44281 Reviewed-on: https://go-review.googlesource.com/c/go/+/191964 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 94bf9a8) Reviewed-on: https://go-review.googlesource.com/c/go/+/191967
tomocy
added a commit
to tomocy/go
that referenced
this issue
Sep 1, 2019
I'm trying to keep the code changes minimal for backporting to Go 1.13, so it is still possible for a handful of entries to leak, but the leaks are now O(1) instead of O(N) in the steady state. Longer-term, I think it would be a good idea to coalesce idleMu with connsPerHostMu and clear entries out of both queues as soon as their goroutines are done waiting. Fixes golang#33849 Fixes golang#33850 Change-Id: Ia66bc64671eb1014369f2d3a01debfc023b44281 Reviewed-on: https://go-review.googlesource.com/c/go/+/191964 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
t4n6a1ka
added a commit
to t4n6a1ka/go
that referenced
this issue
Sep 5, 2019
I'm trying to keep the code changes minimal for backporting to Go 1.13, so it is still possible for a handful of entries to leak, but the leaks are now O(1) instead of O(N) in the steady state. Longer-term, I think it would be a good idea to coalesce idleMu with connsPerHostMu and clear entries out of both queues as soon as their goroutines are done waiting. Fixes golang#33849 Fixes golang#33850 Change-Id: Ia66bc64671eb1014369f2d3a01debfc023b44281 Reviewed-on: https://go-review.googlesource.com/c/go/+/191964 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The following test case fails at
go1.13rc1
due to a leak introduced in CL 184262. The leak occurs due topersistConn
pointers entering theconnsPerHostWait
queue and remaining reachable via that queue until a connection to the host is broken: if connections are never broken, the queue is never cleared.The test passes with that CL reverted, but since that CL fixed a significant deadlock (#32336), I intend to fix the leak (hopefully today) rather than reverting the CL.
CC @bradfitz
The text was updated successfully, but these errors were encountered: