On 01/05/2015 15:03, Rémy Maucherat wrote: > 2015-05-01 11:55 GMT+02:00 Mark Thomas <ma...@apache.org>:
>> So, should we drop one of NIO or NIO2 in Tomcat 9? If not, why not? If >> yes, which one? >> >> I volunteer to help maintain NIO2 for the time being, so I am not in favor > of removing it at the moment. Unfortunately, I think all three connectors > have some good points. > > APR: > - Blocking IO > - OpenSSL (for the time being) If you can get OpenSSL working with the Java connectors then that opens up the question why keep the APR/native connector. But we aren't there yet. > - Sendfile > > NIO: > - It's been around longer :) > - Sendfile > > NIO2: > - Modern async IO > - Scatter / gather IO that can be exposed and taken advantage (see the new > IO calls I added; implementing them with APR and NIO is going to be a whole > lot more convoluted ...) > - Probably HTTP/2 and Servlet.next will take advantage of it just like > websockets did WebSockets didn't take advantage of it scatter/gather. Neither did it take advantage of the async style of API. > I don't think NIO has gotten any better, it's still the most horrendous IO > API imaginable as far as I am concerned. Of course, you can use frameworks > and stuff but ... I agree to keep it as well, since as you say it's more > mature and stable, but that's about it. The main driver for this thinking is reducing complexity in the connectors. Having to support both poller style and async style basic I/O creates complexity. If we only supported one style the I/O code could be a lot cleaner. Overall, I think I prefer the async style. It is much easier to simulate blocking and requires less supporting code (no pollers etc). But, APR uses the poller style and it has much better SSL performance. Thinking ahead (not sure how far, maybe Tomcat 9 at the outside) but if we had OpenSSL working with NIO.2 and performance was similar to the APR/native connector I'd be all for dropping NIO and APR/native in favour of NIO2 and with the option to use OpenSSL or JSSE for SSL. Is that too extreme? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
