Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of costin@gmail.com designates
 64.233.162.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=LOhTXYchBfu3KaYw8emn4kOFOCUiEBkx+jI9mbKU+FnyAwIqhlU4W+9qcBvSgCXtcIcb7bHFN/SKXPM+eHHdW0ebrcBO/vrWBBLKMIrym0umu/VBN1vSabNIZsl1oSACnHmkCnpR4MrI7nPlUx/WsGjA8GbGpNT42p2pZ1qjeSY=
Message-ID: <96e4b5230511181625p4fe6ab68kc1b27f216ceb184b@mail.gmail.com>
Date: Fri, 18 Nov 2005 16:25:25 -0800
From: Costin Manolache <costin@gmail.com>
Reply-To: costin@apache.org
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Any other functionality missing from Tomcat 5.5.12 that relies on
 JSDK 5.0?
In-Reply-To: <437E68CC.3090107@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <6c0aa9500511180700q67d9081jb958d074c7748e6d@mail.gmail.com>
	 <96e4b5230511181159n21e7c61w844517c46921852a@mail.gmail.com>
	 <437E48C9.7070703@apache.org>
	 <96e4b5230511181437v3b2cf083t30227339d6e1c8ba@mail.gmail.com>
	 <437E68CC.3090107@apache.org>

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 curr=
ent
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