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 16:22:39 GMT
Costin Manolache wrote:
> On 10/24/05, Remy Maucherat <> wrote:
>>>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
> I tought there is something for keepalive in the java connector as
> well - I guess I was looking in the wrong place, I know apr can do all
> the cool things, but I couldn't find the equivalent code.
> It may be nice - and maybe that would make the apr and java code share
> more code :-)

No, there's nothing for the "pure" Java connectors. I don't see the 
point of trying to do it in "pure" Java, as:
- all the network code is native anyway, so it depends on if you prefer 
the native network code to come from the ASF or your JVM vendor ;)
- the API exposed to do the same thing in "pure" Java (when they exist) 
are unreasonably complex compared with APR

> It is a way to do even-based IO for servlets - but regardless of name,
> the actual feature can be
> usefull. At least for a sandbox setting :-)  Not a big priority for me
> - I was hoping other people would be interested too.

Did you look at SIP and SIP servlets ? (maybe you did at Motorola) I 
think the specification is complex, but it is actually designed for 
doing this kind of asynchronous IO processing. I don't really understand 
the point of trying to hack stuff based on the Servlet API and/or HTTP 
to do asynchronous processing, since neither has been designed for that.

>>- it encourages a design for servlets which will run very badly on other
>>servlet containers
> Well, long running servlets ( bound to events or slow IO ) will run
> bad anyway on pure threads servers. But if more servers support the
> concept - maybe a good solution would emerge, and become part of a
> future standard. It would certainly be better than seeing it in the
> next servlet spec - without enough implementation experimentation.

This would make the programming model a lot more complex and would act 
funny with web frameworks. Honestly, I'm not hot about it right now.

>>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.
> In the chat room case - you can never get 'instant' messages, you
> depend on the polling
>  frequency.

Yes, it does add significant latency.


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

View raw message