Rémy, On 11/3/14 4:33 PM, Rémy Maucherat wrote: > 2014-11-03 22:00 GMT+01:00 Mark Thomas <ma...@apache.org>: > >> The only times I see NIO go awry these days is in the async code and >> that is as complex as it is partly to support the continued use of BIO. >> >> There was a small hack in 7.0.x for async processing, a larger hack in >> 8.0.x for non-blocking I/O. I suspect an even bigger hack would be >> required in 9.0.x. >> >> If folks don't need async features and want to use BIO simply use Tomcat >> 8. Based on the typical life time of a major Tomcat version that is >> likely to be around for a good few years yet. >> > I wasn't really around when this was discussed, but it is a problem to > advertise support for Servlet 3.1 in the BIO connector. Although the API is > technically implemented, the thread model is not going to be able to > successfully run real apps.
I totally agree, but there are many web applications that use no asynchronous techniques at all. > If there's too much demand for BIO, it could stay with a lot of > unsupported operations exceptions (that would also include upgrade > and 3.1+ non blocking mode this time). This is exactly what I was suggesting. None of the web applications I build and support are using asynchronous models, and we hide behind httpd using mod_jk. We use the BIO AJP connector because we don't need to handle huge numbers of requests and deal with keepalive timeouts and all that stuff: the web server handles that for us. So, the BIO connector provides a clean and efficient path to handle all our requests. I don't see why it should be able to continue to do that. The NIO sim-blocking (which being practical, in contrast to the impractical sim-non-blocking achieved by untold evils in the BIO connector) is kind of hacky and burns unnecessary CPU time when no asynchronous operations are involved. > Comet is probably more significant than BIO for removing old code. Agreed. -chris
signature.asc
Description: OpenPGP digital signature
