Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Message-ID: <53163CBF.7030105@apache.org>
Date: Tue, 04 Mar 2014 20:51:11 +0000
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: NIO 2 connector
References: 
 <CANwj8ZrkH94uRCVh4+Req2V+SDRKHAH=saZ604pEfiMU93020w@mail.gmail.com>
	<53161ADC.9070400@apache.org>
 <CANwj8ZpyKiNyw456=+Q5=GonCGh1V5K0D9rSZ220k++aDUO0eg@mail.gmail.com>
In-Reply-To: 
 <CANwj8ZpyKiNyw456=+Q5=GonCGh1V5K0D9rSZ220k++aDUO0eg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

On 04/03/2014 19:23, R�my Maucherat wrote:
> 2014-03-04 19:26 GMT+01:00 Mark Thomas <markt@apache.org>:
> 
>> On 04/03/2014 16:16, R�my 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 ;)

You are too kind :)

>> 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.

I would like to branch soon. On the other hand if we hold this back
until 9.0.x then it will be a lot longer before folks can really use it.

>>> 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.

I'll try to remember to take a look at it. Maybe just change it to match
the Tomcat major/minor version numbers.

>>> 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.

OK. Thanks.

>>> - Simplicity is sometimes misleading, the API doesn't provide some tools
>>> for the needed synchronization, check pending operations and their
>> possible
>>> optimizations
>>> - SSL is not integrated any better than with NIO1, it is still SSLEngine
>>> 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.

Thanks for the clarifications. I'm +1 with the following caveats:
- no @author tags
- exclude the change that makes NIO2 the default
- document that the NIO2 connector is currently experimental

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org