On 03/11/2014 21:33, 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. 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). > > Comet is probably more significant than BIO for removing old code.
I was going to start with removing BIO but since removing Comet appears to be less contentious I'll start with that. I've been spending the last hour or so looking at our current SPDY implementation. We are going to have issues there as well. It targets SPDY/2 which most browsers no longer support. Servlet 4.0 is targeting HTTP/2 which is going to be roughly SPDY/4+ I don't know how much of the existing SPDY code is going to make sense with HTTP/2 but I do know what we currently have is broken with most browsers. I'm currently leaning towards excluding the current SDPY code from the build until the connector refactoring is complete and then look at it more closely to figure out what we can keep, what needs refactoring and what needs to go. To stand any chance of a robust HTTP/2 implementation I think the connectors need an overhaul. Hence my plans for refactoring. The more duplication and old/obsolete features we can remove the easier this clean up is going to be. Removing BIO support and the associated hacks is part of this clean-up. While I'm not convinced by the need to continue to provide a blocking connector implementation, I'm not against re-instating BIO support once the clean-up is complete if BIO support can be restored cleanly. What I want to avoid is a requirement to have to support a blocking connector to influence the connector refactoring. To put it another way: - drop BIO support now - clean-up the connectors - re-add BIO support (if possible) - all BIO related hacks will be in BIO specific code I'd be prepared to bend that last point depending on what the hack was. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
