2014-03-04 19:26 GMT+01:00 Mark Thomas <ma...@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 ;) > > 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 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. Rémy
