tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: NIO 2 connector
Date Tue, 04 Mar 2014 20:51:11 GMT
On 04/03/2014 19:23, Rémy Maucherat wrote:
> 2014-03-04 19:26 GMT+01:00 Mark Thomas <>:
>> 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/
>> 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):
>>> 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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message