HttpClient infinite HTTP/2 connection pooling

[Daniel Fuchs]

Hi Anton,

There is a PR under review that will provide a system property
to control the maximum time an HTTP/2 connection can remain idle
before being closed by the client:

Please see https://git.openjdk.org/jdk/pull/10183

best regards,

-- daniel

On 21/09/2022 19:50, Anton Keks wrote:
> 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 
> <http://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