Clarification: SETTINGS_MAX_CONCURRENT_STREAMS and STREAM_ID_ERROR

[mkarg]

The HTTP/2.0 protocol allows a server to limit the client's ability to send multiple streams over the same TCP connection using two ways:

• It tells the client the limit using SETTINGS_MAX_CONCURRENT_STREAMS to prevent the client from exceeding the limit
• It sends to the client STREAM_ID_ERROR when the limit is exceed

As a result, Jersey needs to deal with SETTINGS_MAX_CONCURRENT_STREAMS and STREAM_ID_ERROR. Onfortunately it is not documented publicly how Jersey does that. For a better understanding and optimization of HTTP/2 in Jersey it would be beneficial if a member of the Jersey team could briefly outline:

• How can a server application tell Jersey server the limit?
• How does Jersey client react when the calling application exceeds the limit? Will it queue up requests until a slot becomes available, will it open more connections, or will it throw an exception at time of sending the request?
• How does Jersey client notify the calling application about the limit, and about the number of currently available slots?

[jansupol]

I assume you refer to the current HTTP/2 reconnect issue.

At the moment, Jersey relies on Jetty with HTTP/2 support and it goes with the Jetty defaults at the moment. We try to revisit the integration with Jetty to enable the settings if feasible.

[mkarg]

Actually the question was unrelated to any issues.

[senivam]

The first thing - Jersey is JAX-RS implementation. It does not deal with HTTP/2 directly and only uses underlying technologies (connectors/containers) to allow request/response processing. Now Jersey supports HTTP/2 for Jetty container/connector. To set the SETTINGS_MAX_CONCURRENT_STREAMS the property jetty.http2.maxConcurrentStreams shall be set. Regarding all other questions - Jersey only passes the result of client/server communication to the calling application (error states are normally handled by Exceptions). Regarding other questions, you can refer directly to the HTTP/2 client and/or server Jetty documentation part.

[mkarg]

Thank you, Maxim, for chiming in. So to sum up, the answer is: Jersey has no reliable cross-vendor behavior when it comes to the above questions. This is good to know, but maybe we should invent a native API / native property so applications have control over the behavior without using backend-specific code?

[senivam]

In my opinion not having Jersey to handle low-level client/server communication is more of a feature than an issue because this introduces less flows in Jersey as such. On the other hand behavior control of the whole communication flow is usually handled by higher-level frameworks like Helidon which uses Jersey as JAX-RS impl.

[mkarg]

Certainly this is a feature request but not a bug report. ;-)

I do not agree that handling HTTP/2 streams is the job of a higher level framework. Jersey itself is pretty well suited to run outside any larger work as base of mini servers (like embedded) that do not need any more features that what Jersey provides. In fact, HTTP/2 is something that should be handled completely by the lower level. Jersey should only just pass config down to Jetty, so applications do not need to deal with vendor-specifics of Jetty / Helidon, but can rely on vendor-independent JAX-RS configuration mechanism to configure HTTP/2.

[jansupol]

I agree, higher-level frameworks such as Helidon do not use Jersey containers, they use their own. If the feature is to be implemented, it should have been done so in Jersey.