On 04/03/2014 19:23, Rémy Maucherat wrote: > 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 ;)
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
