Naively, looking at the Tomcat documentation and note the comparison
table there makes it appear that:
1. NIO2 offers everything NIO does
2. NIO cannot offer true blocking IO, whereas NIO2 can
If that's not true, then the documentation should be updated at least....
And, of course, NIO2 just sounds newer/better/fancier than NIO :-)
On 5/1/2015 4:55 AM, Mark Thomas wrote:
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?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
