2015-05-01 11:55 GMT+02:00 Mark Thomas <ma...@apache.org>: > Next up on my list is the NIO2 connector. > > NIO and APR/native both use a polling approach to non-blocking I/O. You > add the socket to the poller, tell it what operation (read/write) you > want to perform and then you wait for the poller to tell you the socket > is ready to perform that operation. > > NIO2 uses an asynchronous approach to non-blocking I/O. You perform the > read/write and then wait to be told it has finished via either a Future > or a CompletionHandler. > > Servlet 3.1 non-blocking I/O is closest to the polling style (you get a > callback when you are allowed to read/write). > > WebSocket non-blocking I/O uses the asynchronous style. > > In short, regardless of the underlying approach to non-blocking I/O, we > have to support JavaEE APIs that use both styles. Therefore there is no > 'obvious' advantage for either NIO or NIO2. > > As far as I can tell, the performance of NIO and NIO2 are comparable. > > That raises the question why do we need both NIO and NIO2? And I don't > have an answer to that. If I had to pick one, I'd pick NIO because: > - it has been around longer and is more stable > - it uses the same style as APR/native which may allow further > refactoring to reduce duplication. > > 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) - 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 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. Rémy
