On Tue, 27 Sep 2022 10:58:07 GMT, Michael McMahon <[email protected]> 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 understand that the H2 connection cache is structured slightly differently > to the HTTP/1 idle cache, but I agree that we should try to present the same > view of idle connections across both HTTP/1 and H2. It seems like it should > be possible to record a timestamp when the stream count on a connection goes > to zero, and after a certain time close connections that exceed the current > max idle time. In that situation, it would make sense to use the same > property for both HTTP/1 and H2. OK - thanks @Michael-Mc-Mahon for taking a look. I accept that in the case of idle timeout, there is not much difference in behavior between HTTP/1.1 and HTTP/2 - the property in both cases defines how long the connection will remain open after last being used. I agree that in this case the same timeout value could legitimately be used to configure both pools. It's a bit unfortunate that it's named `keepAlive` rather than `idleTimeout` as `keepAlive` as a stronger HTTP/1.1 connotation - but that's not too bad. Should we also take this opportunity to revisit the default value (1200s is a long time?) ------------- PR: https://git.openjdk.org/jdk/pull/10183
