I honestly don't see the value of keeping BIO around. At this point in time, there can be little else other than an emotional attachment to it. As mentioned in this thread, the APIs and need for more functionality in the connectors have rendered the BIO connector obsolete. If we believe that a Tomcat 9 user would choose BIO for stability (which may have been the case early NIO days), then the solution to that is to fix the NIO connector. The solution should not be supporting the BIO with hacks.
I don't feel this thread has provided any real use cases that would justify BIO remaining alive. For example: >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 ok, fair enough. I actually don't know the state of the NIO AJP connector. And I don't know what level of async or HTTP2 features AJP would even support. >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. Seems to be a contradiction to the previous statement where load was not an issue. I truly don't see how these extra CPU cycles are an issue. And if measured, would they even be noticeable. Having to reimplement BIO, then add hacks around new API's seems like one step forward two steps backwards. Sometimes it may benefit us all to embrace change Filip On Mon, Nov 3, 2014 at 3:08 PM, Mark Thomas <ma...@apache.org> wrote: > 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 > >
