On Mon, Nov 21, 2005 at 11:55:08AM +0100, Remy Maucherat wrote: > Henri Gomez wrote: > >Well why so much noise about NIO/APR ? > > Because I don't want to have to support 20 different connector > technologies (you can call it a business requirement). So one has to be > labelled as "experimental" or something. Similarly, the connector > options right now are (for me) a bit too large. >
Remy, If you think this is a problem why do not you consider making Coyote API more abstract and let people with specific requirements develop their stuff as separate projects outside Tomcat proper, while you can concentrate on developing one or two standard connectors that serve the needs of the majority of users? Presently Coyote API is tightly coupled with the default HTTP implementation, which makes development of third party connectors difficult. Another problem is that some transport layer aspects such as cookie handling are presently implemented in Catalina and are intermingled with application layer aspects whereas they should be implemented by connectors and made customizable to allow for application specific or non-standard behaviours. If Coyote API were more abstract and less dependent on concrete classes in the o.a.tomcat.util package it would foster a greater ecology of smaller projects around Tomcat and would allow interested parties to experiment with alternative connector architectures with minimal to no involvement on the part of Tomcat committers Cheers, Oleg > >If some want to experiment APR or NIO, why can't they do their works > >on some sort of incubations projets and when stable enough give us > >benchmarks results. > > > >Benchmarks/tesings should give us information on : > > > >stability, speed, memory usage, IO usage and of course we should have > >these on many platforms. For example if the alternative implementation > >is running fast as hell on Linux but has no gain on Windows or iSeries > >should we consider it usefull to users ? > > > >Also should we depend on APR on a java centric project ? > > Apparently not ;) > > >I've got no problem with APR, it's a very good piece of code, running > >well even on exotic platforms like iSeries (and probably BS2000 jfc > >?), but should we use a native library as the fundation of Java > >products ? > > The code it replaces in the JVM is all native, written by the JVM > vendor. For most users, it's written by Sun, and parts of it (java.nio > select functionality, for example) have seen reliability issues. Fixing > these kind of problems in this key component (at least in the case of a > web server) requires updating the whole JVM. Besides Sun, and hopefully > the other JVM vendors, I don't see how to actually do support on a NIO > Tomcat. > > APR OTOH is used heavily in a similar production usage on all the > platforms that we want to support. > > >Also since we're speaking about a future Tomcat redesign, shouldn't we > >take care of the future JVM implementations ? Sun, IBM JVMs for now > >but in the future GJC and upcoming Harmony ? If these use APR or > >something similar in native land, should we use APR directly ? > > Unless the said JVMs get certified, I think only a few people are going > to use them for real usage. BTW, yes, APR is still needed, as the JVM > can only expose a small subset of the functionality through java.nio. > > >I'd like to see here pragmatics informations on gains expected when > >using NIO/APR/WHATEVER in real life situations which is what users and > >admins expects. > > I can give a real life example using AJP where the current connector > doesn't work. If you have many front end Apache servers and few Tomcat > servers, since the AJP connections are persistent, the backend servers > will not be able to serve requests. APR allows using a poller for > keepalive, so this solves the problem and the thread count on backend > servers will remain sane. > > >Have a good day and peace on Tomcat Dev community > > Ok :) > > R?my > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
