<div id="geary-body" dir="auto"><div>Thanks Daniel for mentioning it.</div><div><br></div><div><br></div><div>Do you have any background info, why the possibility wasn't there in the beginning?</div><div><br></div><div>And another implementation question is still up: why request (read) timeout on an open connection doesn't close it? </div><div><br></div><div>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.</div><div><br></div><div>That could avoid many problems for many people.</div><div><br></div><div>Anton</div><div><br></div><div><br></div></div><div id="geary-quote" dir="auto"><br>On N, sept  22 2022 at 09:38:46 +0100, Daniel Fuchs <daniel.fuchs@oracle.com> wrote:<br><blockquote type="cite"><div class="plaintext" style="white-space: break-spaces;">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 <a href="https://git.openjdk.org/jdk/pull/10183">https://git.openjdk.org/jdk/pull/10183</a>

best regards,

-- daniel

On 21/09/2022 19:50, Anton Keks wrote:
<blockquote>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 <<a href="http://google.com">http://google.com</a>> 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
</blockquote>
</div></blockquote></div>