On Tue, 27 Sep 2022 14:44:00 GMT, Michael McMahon <micha...@openjdk.org> wrote:
>> **Issue** >> When using HTTP/2 with the HttpClient, it can often be necessary to close an >> idle Http2 Connection before a server sends a GOAWAY frame. For example, a >> server or cloud based tool could close a TCP connection silently when it is >> idle for too long resulting in ConnectionResetException being thrown by the >> HttpClient. >> >> **Proposed Solution** >> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and >> is used to specify in Milliseconds how long an idle connection (idle >> connections are those which have no currently active streams) for the >> HttpClient before the connection is closed. > > I'd agree 1200 sec (20 mins) is way too high. I would think 5-6 mins would be > more appropriate. After discussing with @Michael-Mc-Mahon it seems there is a use case for being able to configure HTTP/1.1 and HTTP/2 keepAlive timeouts independently. It wouldn't be unusual to configure an HTTP/1.1 keepAlive to e.g. 3-5s to have the client close the connection before the sever does, but a better value for HTTP/2 might be in the range of e.g 60s. HTTP/2 specifies a graceful GOAWAY and PING mechanism that allow client & server to cooperate on / detect connection close, which (theoretically) should avoid attempting to reuse stale connections. Maybe we could introduce a new system property, say "jdk.httpclient.keepalive.timeout.h2" which could be used to configure HTTP/2 keepAlive separately. The default value for this property could be taken from "jdk.httpclient.keepalive.timeout". So specifying "-Djdk.httpclient.keepalive.timeout=<timeout>" would configure a global timeout both for HTTP/1.1 and HTTP/2, but "-Djdk.httpclient.keepalive.timeout.h2=<timeout>" could override this value for HTTP/2 if needed. ------------- PR: https://git.openjdk.org/jdk/pull/10183
