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.
andy
_______________________________________________________________________
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
