tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?
Date Sat, 19 Nov 2005 00:25:25 GMT
On 11/18/05, Remy Maucherat <remm@apache.org> wrote:
> Costin Manolache wrote:
> > So for NIO - we should create another copy of 5 large files ? Most of
> > the functions are complete duplicates - a simple extend would eliminate
> > them.
> >
> > The problems are in few abstractions - like Handler - which can be
> > easily fixed to
> > accomodate NIO / APR or traditional.
> >
> > NIO is a valid solution - and may be as fast as APR, in particular
> > with JDK1.6 -
> > and it avoids the JNI layer.
> >
> > I like APR more too - but I don't think it's wise to say there will be
> > no better solution
> > in the future :-) It just happens that today APR is faster - and has a
> > lot of features beyond
> > NIO.
> >
> > IMO the future is in features integrated at the low-level with the VM
> > - in particular
> > if they can bypass JNI or use non-garbage-collected heaps ( as in
> > real-time java ). It
> > would be hard for any JNI solution to beat this - but of course,
> > that's future, not so easy
> > to predict...
>
> I completely disagree. APR is a well accepted IO impl for webservers
> (obviously), and works very well.

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.


> There's room for experimentation as
> separate implementations, but should NIO get better and support the
> features we need (somehow, I doubt the second one will ever be the case
> ...), there's going to be ample time to switch to it later (emphasis on
> later; Java 6 as the Tomcat target is quite far away). In the meantime,
> I don't see the point of yet another abstraction layer.

Not a new abstraction layer - just adjustments to the current one.
For example - add the 'long' socket to TcpConnection - and adjust comments in
TcpConnectionHandler - so it can be used instead of the Handler. Then most Apr
classes could extend the corresponding non-APR classes, and only
override what's
different.

It's not the perfect abstraction - but if you also add NIO, you could
later extract
a base class that has none of the apr/nio/classic methods, and avoid
duplication.
Adding NIO in the same way as APR was added would be a nightmare - the current
APR code is already messy ( Sendfile for example ).

I'm sorry, I like APR, but I can't like the current implementation (
except as a good
initial step ).

Costin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message