tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Sandbox ?
Date Mon, 24 Oct 2005 10:05:27 GMT
Costin Manolache wrote:
> On 10/23/05, Remy Maucherat <> 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.

You need to look a bit into the code ;)

There is:
- APRized HTTP connector with sendfile and poller usage for keepalive
- HTTPS support using OpenSSL
- APRized AJP connector with poller usage for keepalive

> Anyway - this is just a sandbox experiment, we can try different things.
> An unrelated subject - don't know if you saw
> 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.

I don't like it:
- the naming is bad (this is using a poller to get read events, so it's 
basically an IO event mechanism)
- it shouldn't just reinvoke the service method unless it can actually 
just continue transparently execution (also, in the "compatibility" 
mode, the execution path isn't the same), and creates the need for 
proprietary routing logic
- it encourages a design for servlets which will run very badly on other 
servlet containers
- the operations for saving/restoring of the request (basically 
equivalent to FORM) aren't exactly cheap, as well as the usage of a poller

It could be implemented relatively easily in the APRized connectors, but 
given the cost to process a small request over a keepalive connection 
(it's cheap; for example, the use case for this being a chat room, I 
don't see how it would perform bad if using separate requests for each 
message), I don't see any reason to support this.

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

The AprEndpoint does this stuff.


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

View raw message