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
 72.14.204.206 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=Bx1z9mongBRBkM2OAccgl07O07gXYvgZHgN/vIQ9EAb5zh10hluWhNdfB8d4gHfw8JqNJSbWeykoxAgzQ0qca52rWM0ixbEk6K4D+th+mrHgafLkPzHAaxdvYfV3GklWLkVE82vc/IUD97QHuL3dixrnOEW/yej4AAWo8XiaLyg=
Message-ID: <96e4b5230510230833h1b711bbagba107add39acf824@mail.gmail.com>
Date: Sun, 23 Oct 2005 08:33:09 -0700
From: Costin Manolache <costin@gmail.com>
Reply-To: costin@apache.org
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Sandbox ?
In-Reply-To: <435BA32F.2010309@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <96e4b5230510182233y6de73261o15c890ec39e70db3@mail.gmail.com>
	 <002001c5d4ff$2d5ce9a0$0301a8c0@medt01>
	 <96e4b5230510201011l2d8263b0h39d3b3b0530f0f3d@mail.gmail.com>
	 <4359081E.6050208@apache.org>
	 <96e4b5230510210938j43272141mc49825ace1f57035@mail.gmail.com>
	 <435BA32F.2010309@apache.org>

On 10/23/05, Remy Maucherat <remm@apache.org> wrote:

> > I'm thinking more as an 'uses' - you create ByteBuffers ( maybe direct
> > buffers ), and
> > you set it in the ByteChunk. "Extend" is not the best choice - it
> > would be hard to work with direct ( or other ) buffers. I'm actually
> > thinking about adding some static methods as well for all the utils we
> > have in BB.
>
> I didn't do any tests, but accessing direct buffers contents seems
> vastly more expensive. I don't see how they could be used other than for:
> - buffering (as done in the APR connectors)
> - transferring bytes without manipulating them in Java (ex: sending a
> file on a socket)
>
> Did you do some microbenchmarks ?

No - and I'm sure they wouldn't look very good, the current
implementation seems to just do JNI on each operation, so they are
probably more expensive

However - the fact that it is badly implemented now doesn't mean they
can't be implemented better in future or in a different VM :-), i.e.
with special support from the garbage collector, so it can be backed
by an unmovable byte[].  Realtime java JSR requires support for
unmovable objects ( afaik ) - so sooner or later we may have such a
VM, and then direct buffers would be the fastest way to communicate
between java and native.

For sending a file on a socket - I'm sure using apr would be faster (
is sendfile wrapper implemented ? ), you shouldn't have to read the
file in java.

Anyway - this is just a sandbox experiment, we can try different things.

An unrelated subject - don't know if you saw
http://www.mortbay.com/MB/log/gregw/?permalink=3DJetty6Continuations.html

I don't like very much the implementation ( with Exceptions to control
the flow ), but I think there is a good idea to have support in the
thread pool to temporary release the thread for long-running servlets,
and then get a thread back on some event. How this is made visible to
servlets is debatable - I think there are few better ways than what
jetty is doing - but the low level is probably more important.

BTW - where do we deal with keep-alive http connections ? ( I remember
you or Mladen added code to not keep the thread busy ).


Costin

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