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
