3 ms·

Similarly there's no way to shut down an HTTP client, the connection pool sticks around for the duration of the program.

by rendaw 4y ago

lelanthran 4y ago
> Similarly there's no way to shut down an HTTP client, the connection pool sticks around for the duration of the program. I don't understand this - isn't the pool supposed to stick around for the duration of the program? Did you mean that the connection sticks around for the duration of the program?
- cormacrelf 4y ago
  If you make a one shot request to an HTTP server, and the system creates a connection pool for that hostname:port, and you never need it ever again, should the connection pool survive until the program terminates? What if you make hundreds of requests like this? I don’t know how Go buckets their HTTP connection pools, but ADO.NET (the .NET SQL API) does it by connection string, and has a function for freeing all pools and also for one specific pool.
  - lelanthran 4y ago
    > If you make a one shot request to an HTTP server, and the system creates a connection pool for that hostname:port, and you never need it ever again, should the connection pool survive until the program terminates? I did not know it did that, and scanning through the docs, they don't appear to mention it either. Is this only on client programs? Does it do the same for server programs too (create a pool for each incoming src-ip:src-port connections)?
    - cormacrelf 4y ago
      It does have connection pooling for clients: https://blog.cloudflare.com/whats-inside-net-http-socket-late-binding-in-the-go-standard-library/ https://blog.cloudflare.com/whats-inside-net-http-socket-lat.... The pools naturally clear themselves though, because they observe the keep-alive timeouts. As long as your servers are not setting insanely high timeouts you might never notice. Nevertheless it does seem to be impossible to manually clear the pool. This is more of a problem when you realise you can’t use this to temporarily fix a memory leak due to a missing Close() call on a request body or something like that. So in those cases yes it will just leak indefinitely unless you specify an idle timeout in the client constructor as well.
      - rendaw 4y ago
        Or if you're doing http over various types of software tunnels, where automatic cleanup doesn't happen as usual, or there's issues with the upstream server (for internal apis) etc.

Similarly there's no way to shut down an HTTP client, the connection pool sticks around for the duration of the program.

by rendaw 4y ago

Similarly there's no way to shut down an HTTP client, the connection pool sticks around for the duration of the program.

lelanthran 4y ago

> Similarly there's no way to shut down an HTTP client, the connection pool sticks around for the duration of the program. I don't understand this - isn't the pool supposed to stick around for the duration of the program? Did you mean that the connection sticks around for the duration of the program?

cormacrelf 4y ago
If you make a one shot request to an HTTP server, and the system creates a connection pool for that hostname:port, and you never need it ever again, should the connection pool survive until the program terminates? What if you make hundreds of requests like this? I don’t know how Go buckets their HTTP connection pools, but ADO.NET (the .NET SQL API) does it by connection string, and has a function for freeing all pools and also for one specific pool.
- lelanthran 4y ago
  > If you make a one shot request to an HTTP server, and the system creates a connection pool for that hostname:port, and you never need it ever again, should the connection pool survive until the program terminates? I did not know it did that, and scanning through the docs, they don't appear to mention it either. Is this only on client programs? Does it do the same for server programs too (create a pool for each incoming src-ip:src-port connections)?
  - cormacrelf 4y ago
    It does have connection pooling for clients: https://blog.cloudflare.com/whats-inside-net-http-socket-late-binding-in-the-go-standard-library/ https://blog.cloudflare.com/whats-inside-net-http-socket-lat.... The pools naturally clear themselves though, because they observe the keep-alive timeouts. As long as your servers are not setting insanely high timeouts you might never notice. Nevertheless it does seem to be impossible to manually clear the pool. This is more of a problem when you realise you can’t use this to temporarily fix a memory leak due to a missing Close() call on a request body or something like that. So in those cases yes it will just leak indefinitely unless you specify an idle timeout in the client constructor as well.
    - rendaw 4y ago
      Or if you're doing http over various types of software tunnels, where automatic cleanup doesn't happen as usual, or there's issues with the upstream server (for internal apis) etc.