On 11/18/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: > Costin Manolache wrote: > > For C++ servers - yes. > > For Java servers - is anyone else using it besides tomcat ? Even in > > tomcat - how many > > people are using the bindings ( compared with the non-apr connector ) ? > > > > Unfortunately - NIO is the well-accepted solution for java servers ( > > all except tomcat > > are using it ). We know APR is better - but can't pretend it's an > > 'accepted' solution. > > The truth is, few people are using Java web servers, and it's not going > to change. I'm curious to know how NIO is a well accepted solution for > web servers, BTW.
NIO is used AFAIK by Jetty and Resin, and probably others. And it's the 'standard' solution for select-like operations ( even if the standard is as usual not the best solution ). > > I'm sorry, I like APR, but I can't like the current implementation ( > > except as a good > > initial step ). > > Again, I completely disagree. The low level code is small enough that an > abstraction layer is useless. Similarly, a lot of the code in j-t-c/util > should go (starting with the "threads" package). Agree, the threads package shouldn't be used as an API - and a lot of code in j-t-c/util should be deprecated. One of the nice things about NIO is that you can't get rid of a lot of some stuff. Duplicating the entire HTTP parser class just because you don't want a small abstraction ( which was actually already there ) is not right. > To get down to the root of the problem, I don't like the argument that > NIO is any good as an IO API. Besides the (many) utility classes like > the buffers, and as a JNI access method, both of which can be used > without sencond thoughts (and are actually used right now), all the > actual IO code is still all native (no surprise) and the Java API on top > is over engineered. It doesn't make sense to me. Well, most java APIs - including the servlet - are over engineered. And most are far from perfect solution ( again, servlet is a good example :-). Yes, I also hate the way buffers flip and you can't know where is the data ( before or after position ), most of the channel and select are more complex than the APR equivalent. But NIO is a valid solution - with 1.6 I'm pretty sure the performance will be comparable ( with poll, etc ). APR is not the only valid solution ( and on top of that - the way we implement the connector on top of APR is far from either simple or right ). Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
