2014-11-03 20:45 GMT+01:00 Christopher Schultz <[email protected] >:
> > + 2. Remove BIO AJP and HTTP connector. > > I wonder about this goal. Something nice about the BIO connectors is > that they tend to "just work" when other connectors are doing wonky > things. Yes, they seriously complicate things like asynchronous > semantics, but I think it may be more appropriate to simply drop support > for async-over-blocking-IO and otherwise leave the BIO connector in > there (not enabled by default). > > The BIO connectors seem to be the least resource-heavy for when work is > actually being done (as opposed to having 1000 threads sitting idle, of > course) which is a good use case for AJP which pretty much has a > connection limit between httpd <-> Tomcat already. > These BIO connectors "just don't work" (rather than "just work") since they don't implement properly the Servlet 3.1 API. Time to go ... > > > + 3. Remove Comet support. > > Could we package Tomcat 8's Comet components in such a way that they > could be added to Tomcat 9 by someone who might want to upgrade to > Tomcat.latest but still use Comet? I actually think the protocol should > die and from the (lack of) traffic on the list regarding Comet, I > suspect its use is fairly limited. > It is the org.apache.catalina.comet API. It's intrusive, so it's either remove or don't remove. This API is superseded by Servlet 3.1, so this should be removed. > > > + 5. SNI support for JSSE. > > This seems like a feature ripe for back-porting to Tomcat 8 when using a > supportive JVM. > > > + 9. Refactor WebSocket I/O to go directly to Tomcat's internals rather > than via > > + the Servlet API. > > I like this a lot. Is it actually in conflict with my above desire to > continue to support the BIO connectors? > Obviously, it will be another set of APIs that could be "implemented" but would deadlock when used with such a connector. > > > +10. Remove the use of system properties to control configuration > wherever > > + possible > > I like this, too. When anyone is working on moving a system property > into configuration, please think about whether it would make sense (or > be practical) for users to want to set these configuration settings on a > per-web-application or per-host basis instead of only globally. > Obviously, some configurations may only be applicable at the JVM level. > For those, perhaps leaving them as system properties to stress their > "globality" might be a good idea. > > Rémy
