Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
MIME-Version: 1.0
In-Reply-To: <53161ADC.9070400@apache.org>
References: 
 <CANwj8ZrkH94uRCVh4+Req2V+SDRKHAH=saZ604pEfiMU93020w@mail.gmail.com>
	<53161ADC.9070400@apache.org>
Date: Tue, 4 Mar 2014 20:23:36 +0100
Message-ID: 
 <CANwj8ZpyKiNyw456=+Q5=GonCGh1V5K0D9rSZ220k++aDUO0eg@mail.gmail.com>
Subject: Re: NIO 2 connector
From: =?ISO-8859-1?Q?R=E9my_Maucherat?= <remm@apache.org>
To: Tomcat Developers List <dev@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=089e013c6f9c35e49b04f3ccd762

--089e013c6f9c35e49b04f3ccd762
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2014-03-04 19:26 GMT+01:00 Mark Thomas <markt@apache.org>:

> On 04/03/2014 16:16, R=E9my Maucherat wrote:
> > Hi,
> >
> > I've been working on porting a NIO2 connector that was originally
> developed
> > for JBoss AS by Nabil Benothman (an intern at Red Hat). Due to the very
> > different connector structure in Tomcat and my preference for basing it
> on
> > the existing NIO1 connector, it is mostly new code, though.
>
> There looks to be opportunities to share code with the current NIO
> connector.
>

Don't know. I used the structure, but the algorithms are quite different.
You'll have the opportunity to do it if you want of course ;)

>
> There are some changes to the existing code, such as
> java/org/apache/coyote/http11/upgrade/AbstractServletInputStream.java
> that I would like to understand.
>

Nothing special, it needs a first read to start its "polling", so that's
the reason for adding isReady() (normally harmless). I added the third
event method too for consistency, and that's it.

>
> > So I would now like to contribute this in trunk as a new experimental
> > connector. It should have feature parity with the NIO1 connectors. Of
> > course, while the basics are in, it will need some time to pass the
> > testsuite, fix issues, improve stability, etc.
>
> Can you wait until we split 8.0.x from trunk or did you want to get this
> into 8.0.x?
>

Depends, if you want to branch soon or not. It would have to be
experimental for a while anyway, but it will likely bring something useful.

>
> > Coyote version number could be moved up to 2.0 with this addition along
> > with all the connector refactorings that Mark did in trunk.
>
> I'd rather drop the version number entirely as it is pretty much
> meaningless. If we are going to do that, we may as well change the
> server header to "Apache Tomcat". I'm neutral on whether to include the
> major or full version number.
>

I think the spec says there should be a /0.0 version number, and I like the
Coyote name, but you can change it.

>
> > The code is there (rebased to the current trunk):
> > https://github.com/rmaucher/tomcat
> >
> > A quick NIO2 (the API) presentation.
> >
> > Pros:
> > - Significantly faster, although the API looks slower by design
> > - Resources friendly
> > - Seemingly trivial to use
> >  - Polling is neatly hidden away
> > - Thread pool is also neatly hidden away
> > - Per operation timeouts
> > - Read/Write is symmetric
> > - Trivial blocking IO
> >
> > Cons:
> > - No real non blocking IO
>
> Hmm. I was considering dropping the BIO connector entirely for Tomcat 9
> because of its inability to do non-blocking IO and the way the Servlet
> API was heading. Does it make sense to add a different non-blocking
> connector implementation or have I misunderstood your point?
>

Well, nobody is going for non blocking IO, people are using async IO.

But then obviously the read(ByteBuffer) call which used to return an int
(possibly 0 with non blocking IO) now returns a Future<Integer>. And if you
want to know the result you have to wait for it and there's an IO operation
pending the entire time. So that's the "cons".

It would be nice to have non blocking operations for "peek" scenarios. So
instead to peek a read, you have to read with a completion handler, then
see if it returns inline. And if it doesn't there's an async process now
doing IO (possibly not the greatest thing that could happen).

>
> > - No concurrency allowed [for the socket impl of NIO2] although the API
> > looks concurrent
>
> Do you mean no concurrent read and writes? That would be a huge issue.
>

No, don't worry, that works. It's concurrency on the same operation (like
read, write, accept). The API looks relatively magic, so you'd think you
could do it.

>
> > - Simplicity is sometimes misleading, the API doesn't provide some tool=
s
> > for the needed synchronization, check pending operations and their
> possible
> > optimizations
> > - SSL is not integrated any better than with NIO1, it is still SSLEngin=
e
> > which leads to creating the obligatory "AsynchronousSSLSocketChannel"
> > wrapper class yourself
> > - No real sendfile
> >
> > Comments ?
>
> The pros look nice but I am worried about the cons.
>
> The summary is that in the worst case, it's much better.

R=E9my

--089e013c6f9c35e49b04f3ccd762--