Remove async message receivers
------------------------------
Key: AXIS2-2800
URL: https://issues.apache.org/jira/browse/AXIS2-2800
Project: Axis 2.0 (Axis2)
Issue Type: Improvement
Reporter: Glen Daniels
Srinath was working on http://issues.apache.org/jira/browse/AXIS2-1363, and we
here at the hackathon got involved in a discussion about asynchrony on the
server side. To make a long story short, we decided that it's overkill to make
the user specify an asynchronous MessageReceiver in order to get the behavior
of spawning a worker thread to do the actual business logic.
We'd like to instead have a property on the MessageContext (which can of course
be set on the operation or service) which specified whether or not to prefer
separate threads. If this "preferSeparateThread" property is TRUE, then we
will spin off a separate thread to do the business logic *if* we're using
another channel for the response - if we're using the backchannel (WSA
anonymous or no WSA), there's no real point in spinning off a thread since the
current thread is most likely going to have to wait around for the response
anyway.
We propose to put this logic in AbstractMessageReceiver.receive(), and to head
towards deleting AbstractAsyncMessageReceiver and all its subclasses (simpler
code is better code!) by deprecating them for 1.3. We can actually delete them
in a release or two.
(Interesting code tidbit - the RPCMessageReceiver and the
RPCInOutAsyncMessageReceiver are, code-wise, just about IDENTICAL except for
their parent class and whitespace!)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
