2015-09-10 10:51 GMT+02:00 Mark Thomas <ma...@apache.org>:

> On 10/09/2015 09:36, Rémy Maucherat wrote:
> > 2015-09-10 10:13 GMT+02:00 jean-frederic clere <jfcl...@gmail.com>:
> >
> >> Hi,
> >>
> >> I have a wording questions from my ApacheCon presentations, I am using
> >> tomcat9 to speak about trunk but basically tomcat9 should be with java9
> and
> >> the new servlet specifications. AKA far future.
> >>
> >
> > I'm not sure it will require Java 9. Using ALPN would require either
> Java 9
> > or OpenSSL, I think that is going to be the most likely scenario, so
> Java 8
> > would remain quite usable.
>
> +1. We are going to have to find a way to work with ALPN and Java8. The
> OpenSSL + NIO/NIO2 option looks like the way to go at the moment.
>

There's another major issue with straight Java 8: its JSSE performance is
horrible for the "current" ciphers. So even if ALPN was somehow added, it
is rather useless for HTTP/2.

>
> >> It will be probably interesting to promote an intermediate tomcat
> version
> >> with HTTP/2 and related features but without a servlet 4.0  do we want
> to
> >> do that?
> >>
> >
> > Yes, the problem is that the next EE is too far away. A new 8.x would
> have
> > to supersede the current 8.0 though otherwise it would be too difficult
> for
> > maintenance. However, there are significant addition/changes to the
> > configuration in trunk.
>
> HTTP/2 isn't stable right now. One of my more recent changes (I suspect
> the old stream clean-up) is triggering crashes with APR. I should be
> able to get that fixed in time for ApacheCon and put together a
> 9.0.0.ALPHA release.
>

Ok, I agree it's a bit early right now.

My current testing (with JF) with browsers (chrome and firefox) is:
- APR works perfect (no crash for me)
- NIO works ("perfect"is missing)
- NIO2 fails quickly (with chrome, it doesn't get past the client settings
frame)

Trying to debug NIO2, I haven't found anything wrong, nothing seems
corrupted, IO is working (that's easy to see since it's a regular
read/write before passing data to/from the SSL engine), etc, but the
browser doesn't like it [without explanation of course].

>
> Back-porting HTTP/2 (once it is stable) to 8.x would require
> back-porting the connector clean-up which in turn means dropping BIO and
> comet support for an 8.1.x release series. I think it would be worth
> gauging community reaction to such a move first since I agree we would
> have to stop support for 8.0.x. It might be preferable to have 9.0.x
> BETA releases that are only beta because the Servlet API is not fixed.
>
> I don't exactly know what is in trunk that couldn't be in a 8.1. The
removals of existing features make a lot of the rest probably acceptable.
The EE schedule saying 2017, it's really a looooong time to be in beta [or
not maybe ;) ].

Rémy

Reply via email to