On 02/05/2015 21:52, Rémy Maucherat wrote: > 2015-05-01 19:28 GMT+02:00 Mark Thomas <ma...@apache.org>: > >> 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. >> > > Websockets could easily take advantage of it. For example the code in > WsRemoteEndpointImplServer and all its for loops over arrays of buffers to > write them looks rather close to a gather write to me and could probably > all be replaced with a single write.
I agree it could. My point was that, contrary to your original statement, it doesn't currently. APR/native looks to have support for gathered write as well. There is definitely scope to simplify WebSocket code. NIO would still need the loop over the arrays but that would move to the NIOSocketWrapper. >>> 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. > > Of course, things can always be cleaner, but this causes issues. For > example, the one I dislike the most is NIO, but as you said it is the most > stable, so removing it is probably not a good idea. Right now, I agree with that assessment. >> 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. > > I was planning to send an email about that on Monday, so I guess I'm > sending it now instead. > >> Is that too extreme? >> > The list of "pros" for each connector is not empty, so I don't see why it > helps to remove one. Looking some time further ahead where NIO2 is as stable as NIO and there is an OpenSSL option for SSL/TLS with NIO2 I don't see any advantages of NIO or APR/native over NIO2 which raises the possibility - at that point - of just having NIO2. At this point I'm not proposing anything - just putting the idea out there for discussion. I think we are a long way off being in a position to drop any of the connectors at this point. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
