HttpClient infinite HTTP/2 connection pooling

[Anton Keks]

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 
<daniel.fuchs at oracle.com> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20220923/62c8d0f8/attachment.htm>