On Mon, 2015-03-02 at 17:43 +0100, Francois-Xavier Bonnet wrote: > Hi, > > ALPN implementation from Jetty does not require Java 8 but it requires > OpenJDK (not Oracle and at least OpenJDK 1.7.0u40), in addition there is a > specific version of ALPN for each minor version of OpenJDK, and it has to > be in the boot classpath of the jvm. > I don't think we need to rush to Java 8 because of HTTP/2. We can do just > like Jetty which still works on Java 7 and only checks at runtime for > OpenJDK and ALPN when you want to turn on SPDY or HTTP/2 >
Hi Francois-Xavier Thanks for pointing that out. I am not going to upgrade the trunk to Java 7 for now. Cheers Oleg > > 2015-02-28 14:35 GMT+01:00 Oleg Kalnichevski <[email protected]>: > > > (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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
