You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Glen Daniels (JIRA)" <ji...@apache.org> on 2007/06/12 23:14:48 UTC
[jira] Created: (AXIS2-2800) Remove async message receivers
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [jira] Created: (AXIS2-2800) Remove async message receivers
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
I'm fine with this improvement but curious as to how the user would be
able to set this property in the MC. Is there some module that's spsed to
do that?? Sorry; I'm missing a link (no, not the missing link).
Sanjiva.
Glen Daniels (JIRA) wrote:
> 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!)
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Resolved: (AXIS2-2800) Remove async message receivers
Posted by "Glen Daniels (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Glen Daniels resolved AXIS2-2800.
---------------------------------
Resolution: Fixed
Done. The property lives in AbstractMessageReceiver.DO_ASYNC, and is "messageReceiver.invokeOnSeparateThread".
> 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
> Assignee: Glen Daniels
> Fix For: 1.3
>
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-2800) Remove async message receivers
Posted by "Glen Daniels (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Glen Daniels updated AXIS2-2800:
--------------------------------
Fix Version/s: 1.3
> 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
> Fix For: 1.3
>
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Assigned: (AXIS2-2800) Remove async message receivers
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Deepal Jayasinghe reassigned AXIS2-2800:
----------------------------------------
Assignee: Glen Daniels
> 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
> Assignee: Glen Daniels
> Fix For: 1.3
>
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org