tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?
Date Sat, 19 Nov 2005 04:36:50 GMT
On 11/18/05, Remy Maucherat <> 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 ).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message