Thanks Daniel for mentioning it.
Do you have any background info, why the possibility wasn't there in
the beginning?
And another implementation question is still up: why request (read)
timeout on an open connection doesn't close it?
Or basically, if no request on the connection succeeds, maybe that
could be a reason to close it automatically? Especially if it has been
open for very long time.
That could avoid many problems for many people.
Anton
On N, sept 22 2022 at 09:38:46 +0100, Daniel Fuchs
<[email protected]> wrote:
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 <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
