HttpClient infinite HTTP/2 connection pooling

[Anton Keks]

Hello!

While debugging production issues with our payment system integration that
frequently gets HttpTimeoutExceptions I stumbled upon the fact that:

* HTTP/1 connections are pooled using the ConnectionPool class and both
pool size and maximum keepalive time can be controlled using system
properties
* HTTP/2 connections are pooled in Http2ClientImpl.connections map, which
doesn't have any controls for number of pooled connections or their
lifetime.

Despite the fact that most people assume that ConnectionPool properties
also apply for HTTP/2 connections, there is a real possibility for
unsolvable problems with HTTP/2 connections that stay in the pool for too
long (hours).

Most HTTP/2 servers send GOAWAY packets after some time (e.g. google.com
after 4 minutes) and the connections get removed from the pool.

But if the server doesn't send GOAWAY, then the connection can be
killed/expire on the network (router) level without ever delivering an RST
or anything back. In the case I mentioned above, it happens in reality:
somehow the connection doesn't work anymore, but HttpClient still assumes
it is working and sends new requests to it without ever hearing back and
producing HttpTimeoutException.

Currently it seems the only non-hacky workaround for this problem is
downgrading to HTTP/1 on the HttpClient level.

So the questions:
* Why HTTP/2 connection pool cannot be controlled at all?
* Why HttpTimeoutException still keeps the connection in the pool?

Thanks for any comments,
Anton
//codeborne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20220921/c04b0c17/attachment.htm>