(1) HTTP/2 multiplexing is simply impossible to implement efficiently with classic (blocking) I/O. A single HTTP/2 connection now represents multiple full duplex streams of data. The connection can simply not block doing just one thing, like writing out a lengthy message content body in one stream while completely blocking out all other streams. While I cannot completely rule out the idea of implementing just a subset of HTTP/2 with blocking I/O at some point, it does look like we should focus on exclusively on non-blocking code and seriously consider getting rid of blocking components at some point.
(2) HTTP/2 invalidates a lot of previous design decisions (*) Given that data is now being transferred in fairly small chunks for multiple independent streams it is no longer important or even desirable to let non-blocking protocol handlers have direct access to the underlying connection channel. This pretty much invalidates the entire design of the I/O reactor layer. The I/O reactor layer is likely to require a complete re-design and rewrite. (*) Multiplexing and TLS encryption makes zero-copy transfer mode pretty much impossible and irrelevant terms of performance optimization. (3) Fully compliant deployments of HTTP/2 are _required_ to negotiate supported protocols using TLS Application-Layer Protocol Negotiation Extension (RFC 7301) which is not even supported by Java at the moment [1] and likely to become available in Java 9 only. There is a hack of sort developed by Jetty folks that make this extension somehow work with Java 8 but I have not looked at it yet. Regardless, it looks like we have to upgrade to Java 8 no matter what. This, again, poses a difficult question whether we should rush HC 5.0 with HTTP/1.1 only and introduce HTTP/2 in HC 6.0. This would enable us to delay inevitable upgrade to Java 8/9 for those folks who are only interested in HTTP/1.1. (4) We might need introduce logging support at HttpCore level simply because the transport logic is massively more complex now. Back to logging wars. (5) Client side connection pooling becomes much, much less relevant. Probably even irrelevant. This eliminates a considerable advantage HC have over competing client side HTTP implementations. (6) We should be able to re-use all existing protocol handling code with HTTP/2. The good news is that HTTP/2 is conceptually elegant and very flexible. It addresses pretty much all short-comings of HTTP/1.1 I can think of. Oleg PS: There likely to be other thoughts I would want to share as my work progresses. More posts to come. PPS: I am working on HTTP/2 frame handling code at the moment (the low level data frame transport stream multiplexer code will be based upon). If anyone wants to see early code please let me know [1] https://bugs.openjdk.java.net/browse/JDK-8062848 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
