Filip, On 11/3/14 10:15 PM, Filip Hanik wrote: > 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.
No, what I meant was that connection-load was not an issue (e.g. we wouldn't have to configure 1M connections just to support keepalive timeouts, etc. that plague BIO configurations). Each individual NIO thread takes more CPU resources due to the sim-blocking that is required to perform blocking I/O for the original stream-based APIs for servlets. The testing that jfclere and I did and presented at last year's ApacheCon NA showed a detectible difference in CPU load for the NIO versus BIO connectors for the same real load (req/sec). We didn't do any testing to determine if that represented a real effect on other processes that needed to accomplish work, but it did have a pretty significant impact on the system's "busy" versus "idle" percentages. > Having to reimplement BIO, then add hacks around new API's seems like one > step forward two steps backwards. I agree. My proposal was to not really hack anything if at all possible. Instead, just drop BIO support for those items which require a hack. Supporting BIO for the stream-based I/O (blocking) APIs seems like it shouldn't really require Earth-moving equipment. > Sometimes it may benefit us all to embrace change I'm happy to let the BIO connectors die if nobody wants to support them. I just wanted to point-out that there are real use cases for their continued existence. (And I happen to fit into one of those use-cases :) -chris
signature.asc
Description: OpenPGP digital signature
