http2-examples | Example code for the blog posts on http : //fstab | Blog library

I'm pretty sure, at this moment you can't get streamId generated and used by Netty. Also, I don't like the idea of increasing streamId by myself too, but looks like it's okay to do this with current API.

I've checked Netty sources and found next things:

1. HttpToHttp2ConnectionHandler is used for writing requests. It has private method getStreamId which is used in write method for getting value of currentStreamId. But we doesn't have any access to this variable.
2. getStreamId method uses another method called incrementAndGetNextStreamId. So, again, we can only increment and get new streamId value but can't get the current one.

Both of these classes marked with annotation @UnstableApi, so maybe this behavior will be change in the future.

Here's some related links:

1. A little bit updated HTTP 2 client example from Netty repository.
2. HTTP/2 Java Client Examples.
3. Why netty http2 server always use odd number for streamId.

Disclaimer, I am the Jetty HTTP/2 maintainer.

Given that you have a large number of clients and that processing could take seconds, I would recommend to go with option 1 - async servlet and Jetty HTTP/2 client.

With "async servlet" you have 2 flavors: 1) async processing with blocking I/O, or 2) async processing + async I/O.

Servlet async processing is triggered by the use of HttpServletRequest.startAsync().

Servlet async I/O is triggered by using ReadListener and WriteListener respectively with the ServletInputStream and ServletOutputStream.

You definitely want async processing because you have a large number of clients and processing in the order of seconds - this will optimize the use of server threads.

Whether or not to use async I/O should probably be measured, since you have small binary responses. Blocking I/O is much much easier to code and debug, while async I/O is definitely more complicated to code and debug. Async I/O really shines when you have large contents and slow clients that may congest the TCP connection.

If you want to be fully async, go with async I/O. If you can tolerate a bit of blocking in exchange of simpler code, stay on blocking I/O. Worth repeating, in both cases - either async I/O or blocking I/O - you want to use async processing.

Regarding the issue of copying data, if you are willing to cast down to Jetty classes, you can avoid the copy by directly writing a ByteBuffer to the ServletOutputStream subclass, see this example.

Finally, with the Jetty client you can use the high-level HttpClient with the HTTP/2 transport as detailed here. The benefit would be a high-level API that only deals with HTTP concepts, rather than using the low-level HTTP2Client that deals with HTTP/2 frames, streams and such.

Report back what you end up choosing, and how it goes for you !