You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Jetty version(s)
Jetty 11, including Jetty 11.0.15
Enhancement Description
Timeouts are configurable at several places when starting a Server, but the H2 streamIdleTimeout doesn't support being disabled without also disabling all timeouts on the same connector.
This isn't the typical H2 "keep-alive" timeout, but seems to be something specific to Jetty, allowing a server to prevent long-running streams.
HTTP2Session gets the value for streamIdleTimeout initially from Endpoint.getIdleTimeout(), which in turn gets the value from AbstractConnector.getIdleTimeout() - a general value that is used for effectively all timeouts.
This makes it tricky to specify that other timeouts are acceptable in their default configuration, but long-running H2 streams to clients might be permitted to have longer delays between messages.
Workaround
As a workaround, it is possible to create a listener on the ServerConnector, and listen for HTTP2ServerConnection instances as they are created, and directly configure the session's timeout value.
// Override the h2 stream timeout with a specified valueserverConnector.addEventListener(newConnection.Listener() {
@OverridepublicvoidonOpened(Connectionconnection) {
if (connectioninstanceofHTTP2ServerConnection) {
HTTP2Sessionsession = (HTTP2Session) ((HTTP2Connection) connection).getSession();
session.setStreamIdleTimeout(0);// Disable timeout
}
}
@OverridepublicvoidonClosed(Connectionconnection) {
}
});
Related
Note that disabling stream idle timeouts appears to be another workaround for #8405, though that issue is about the client listening to a server stream, and even if the timeout isn't disabled, the stream will not stop after the timeout - instead, the bug will manifest, where onAllDataRead() is called twice, once before the server has finished sending.
Possible fix
It might be possible to simply remove the > 0 check in AbstractHTTP2ServerConnectionFactory.newConnection, either relaxing it to >= 0, or permitting negative values.
The text was updated successfully, but these errors were encountered:
niloc132
changed the title
Http2Session.streamIdleTimeout should permit being disabled
Http2Session.streamIdleTimeout should permit being disabled from AbstractHTTP2ServerConnectionFactory
May 1, 2023
…bled
Now allowing to specify a negative value for AbstractHTTP2ServerConnectionFactory.streamIdleTimeout, while 0 implies to use the default value (from the EndPoint).
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
…bled
Now allowing to specify a negative value for AbstractHTTP2ServerConnectionFactory.streamIdleTimeout, while 0 implies to use the default value (from the EndPoint).
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Jetty version(s)
Jetty 11, including Jetty 11.0.15
Enhancement Description
Timeouts are configurable at several places when starting a Server, but the H2 streamIdleTimeout doesn't support being disabled without also disabling all timeouts on the same connector.
This isn't the typical H2 "keep-alive" timeout, but seems to be something specific to Jetty, allowing a server to prevent long-running streams.
HTTP2Session gets the value for streamIdleTimeout initially from Endpoint.getIdleTimeout(), which in turn gets the value from
AbstractConnector.getIdleTimeout()
- a general value that is used for effectively all timeouts.It is also possible to set a more specific stream idle timeout on
AbstractHTTP2ServerConnectionFactory
's streamIdleTimeout property, but unfortunately any non-positive value will be ignored:https://github.com/eclipse/jetty.project/blob/d1195b512340e9ab694fe5bb57b5615b437a475a/jetty-http2/http2-server/src/main/java/org/eclipse/jetty/http2/server/AbstractHTTP2ServerConnectionFactory.java#L268-L274
This makes it tricky to specify that other timeouts are acceptable in their default configuration, but long-running H2 streams to clients might be permitted to have longer delays between messages.
Workaround
As a workaround, it is possible to create a listener on the ServerConnector, and listen for HTTP2ServerConnection instances as they are created, and directly configure the session's timeout value.
Related
Note that disabling stream idle timeouts appears to be another workaround for #8405, though that issue is about the client listening to a server stream, and even if the timeout isn't disabled, the stream will not stop after the timeout - instead, the bug will manifest, where onAllDataRead() is called twice, once before the server has finished sending.
Possible fix
It might be possible to simply remove the
> 0
check in AbstractHTTP2ServerConnectionFactory.newConnection, either relaxing it to>= 0
, or permitting negative values.The text was updated successfully, but these errors were encountered: