<div dir="ltr"><div>Hello!</div><div><br></div><div>While debugging production issues with our payment system integration that frequently gets HttpTimeoutExceptions I stumbled upon the fact that:</div><div><br></div><div>* HTTP/1 connections are pooled using the ConnectionPool class and both pool size and maximum keepalive time can be controlled using system properties</div><div>* HTTP/2 connections are pooled in Http2ClientImpl.connections map, which doesn't have any controls for number of pooled connections or their lifetime.</div><div><br></div><div>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). </div><div><br></div><div>Most HTTP/2 servers send GOAWAY packets after some time (e.g. <a href="http://google.com">google.com</a> after 4 minutes) and the connections get removed from the pool. </div><div><br></div><div>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.</div><div><br></div><div>Currently it seems the only non-hacky workaround for this problem is downgrading to HTTP/1 on the HttpClient level.</div><div><br></div><div>So the questions:</div><div>* Why HTTP/2 connection pool cannot be controlled at all?</div><div>* Why HttpTimeoutException still keeps the connection in the pool?</div><div><br></div>Thanks for any comments,<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Anton<br>//codeborne<br></div></div></div>