You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By default, Transport caches connections for future re-use. This may leave many open connections when accessing many hosts. This behavior can be managed using Transport's CloseIdleConnections method and the MaxIdleConnsPerHost and DisableKeepAlives fields.
For users of the API, it may not be obvious that the idle connections may remain open even after the Transport becomes unreachable and is garbage-collected.
It would be nice if the zero-value Transport represented a configuration that did not leak connections. Better still if we could find a way to automatically close the idle connections when the Transport becomes unreachable.
I don't think this is fixable in Go 1, but we should revisit this aspect of the API if/when we're thinking about Go 2.
earlier question: why are users creating their own Transports? It'd be nice to understand that first.
Finalizers, in addition to being terrible, don't really help here since the goroutines run by the Transport also reference the Transport.
we could introduce a default Transport.IdleTimeout value. It's hard to argue go1compat there since servers can hang up on you at any moment randomly. To say "really, really forever" we could respect a negative time.Duration. But any default we picked (say, 60 seconds or 5 minutes) is still too long for people creating Transports in a loop. So that doesn't really help.
The documentation for http.Transport warns:
For users of the API, it may not be obvious that the idle connections may remain open even after the
Transport
becomes unreachable and is garbage-collected.It would be nice if the zero-value Transport represented a configuration that did not leak connections. Better still if we could find a way to automatically close the idle connections when the Transport becomes unreachable.
I don't think this is fixable in Go 1, but we should revisit this aspect of the API if/when we're thinking about Go 2.
(@bradfitz @dsnet @tokkee)
The text was updated successfully, but these errors were encountered: