A possible file descriptor leak in ClientManager? about apns2

[imhoffd]

@cissoid Odd. Once the Client is removed from the ClientManager, the reference to it should be lost and Go should GC it and close the connections automatically, shouldn't it? Is there anything in the code that doesn't exhibit that behavior?

Each client has its own Transport, which means calling CloseIdleConnections() on it won't affect other clients. I would be concerned when a client is "checked out" from the ClientManager and being used. CloseIdleConnections() wouldn't affect it, but it also wouldn't clean up after itself properly when the client is removed.

[cissoid]

@dwieeb

Once the Client is removed from the ClientManager, the reference to it should be lost and Go should GC it and close the connections automatically

I took a look at go source code. After connection created, there will start a new goroutine to run read loop, so there's should have another reference point to the connection, see https://github.com/golang/net/blob/master/http2/transport.go#L573.

The read loop will close connection only if keepalive on current connection is disabled, and exit loop only when read error, see https://github.com/golang/net/blob/master/http2/transport.go#L1458.

I'm not sure but this might be the reason.

[imhoffd]

@cissoid That behavior makes sense, I suppose. We could set DisableKeepAlives to true on the transport after a client is removed.

[cissoid]

@dwieeb That not works, DisableKeepAlives only checked when read loop starting, change it after connection created seems no effect.