tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Piper <>
Subject Re: Greg Wilkins' blog on async servlet API
Date Tue, 23 May 2006 09:46:26 GMT

>At 12:38 AM 5/20/2006, Remy Maucherat wrote:
> >Costin Manolache wrote:
> >>I agree, it's not  very intuitive - but it's still good to understand it,
> >>and maybe learn from
> >>what we like and don't like it :-) It's hard to make something simple,
> >>intuitive, easy
> >>to implement, high performance, flexible - all at the same time.
>There is a simpler internal API in weblogic but it has a number of
>user-level issues:
>1. It doesn't cope with pushing thread contexts when processing
>requests (e.g. context classloader, current transaction etc).
>2. It doesn't deal with the need to eventually timeout pending
>requests to avoid memory leaks.
>3. It requires detailed knowledge of when to perform certain actions,
>when to write to streams etc. It also requires knowledge of how to
>write a scalable rendezvous for processing the callbacks. All of
>these things are tricky for users to get right, so we would prefer to
>provide an API that removes some of these problems.
>The API itself is designed to handle the common server-side case of
>wanting to process servlet reponses at a later date without tying up
>threads in the interim. I assume this is what you mean by input?
>doRequest() is called in the same way as service() and it is up to
>the developer to stash away the key and call notify() with that key
>when he wants to process the response. doResponse() is then called
>with appropriate context etc.
>We originally did not use a key, but there's actually a nasty
>synchronization problem that cannot be solved without this.
>doTimeout() is called if the request is timed out without notify ever
>being called.
>If by output you mean the issue of making an http request and waiting
>asynchronously for the response. We have an implementation of this
>but it is not public since its a slightly more unusual use-case for a
>web server.

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

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

View raw message