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 "Thilina Gunarathne (JIRA)" <ji...@apache.org> on 2005/11/15 14:11:28 UTC
[jira] Created: (AXIS2-304) InOnly MEP blocks the caller till the operation finishes.......
InOnly MEP blocks the caller till the operation finishes.......
---------------------------------------------------------------
Key: AXIS2-304
URL: http://issues.apache.org/jira/browse/AXIS2-304
Project: Apache Axis 2.0 (Axis2)
Type: Bug
Components: core
Reporter: Thilina Gunarathne
The above behaviour of the InOnly MEP causes the long running activities to timeout + It's ruining the advantages behind one way messaging......
Quoting Dr.Sanjiva,
when we get a message after dispatch is finished we know the MEP. If the MEP is In-Only, then we should immediately hand over the delivery of the message to a thread and return the original thread
Related to the following threads in the Dev list,
http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2572316.html
http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2296180.html
Fixing this might help to overcome the following in User list,
http://www.opensubscriber.com/message/axis-user@ws.apache.org/2464960.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Resolved: (AXIS2-304) InOnly MEP blocks the caller till
the operation finishes.......
Posted by Deepal Jayasinghe <de...@opensource.lk>.
you can still use RawXMLINOnlyMessageReceiver, but as you said if the
request take longer time than its better to use Async message receiver,
but you have to right your own async message receiver. I think it better
we can have set of async message receivers as well, before the next
release I will implement them all :)
robert lazarski wrote:
> Deepal, I'm trying to test a long fire and forget call with the latest
> svn and I'm confused. What receiver goes in services.xml ? Before it
> was RawXMLINOnlyMessageReceiver - is this now for sendRobust (which
> currently throws unsupported operation)? I see a AsyncMessageReceiver
> that extends AbstractInOutAsyncMessageReceiver - but its under
> modules/integration/test .
>
> Robert
> http://www.braziloutsource.com/
>
> On 3/13/06, *Deepal Jayasinghe (JIRA)* < jira@apache.org
> <ma...@apache.org>> wrote:
>
> [ http://issues.apache.org/jira/browse/AXIS2-304?page=all ]
>
> Deepal Jayasinghe resolved AXIS2-304:
> -------------------------------------
>
> Fix Version: 0.95
> Resolution: Fixed
>
> - Clien side is sloved with ServiceClinet.firAndForget()
> - In the server side , if you use Async message receiver then you
> are done
>
> > InOnly MEP blocks the caller till the operation finishes.......
> > ---------------------------------------------------------------
> >
> > Key: AXIS2-304
> > URL: http://issues.apache.org/jira/browse/AXIS2-304
> > Project: Apache Axis 2.0 (Axis2)
> > Type: Bug
> > Components: core
> > Reporter: Thilina Gunarathne
> > Fix For: 0.95
>
> >
> > The above behaviour of the InOnly MEP causes the long running
> activities to timeout + It's ruining the advantages behind one way
> messaging......
> > Quoting Dr.Sanjiva,
> > when we get a message after dispatch is finished we know the
> MEP. If the MEP is In-Only, then we should immediately hand over
> the delivery of the message to a thread and return the original thread
> > Related to the following threads in the Dev list,
> >
> http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2572316.html
> <http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2572316.html>
> >
> http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2296180.html
> > Fixing this might help to overcome the following in User list,
> >
> http://www.opensubscriber.com/message/axis-user@ws.apache.org/2464960.html
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>
--
Thanks,
Deepal
................................................................
~Future is Open~
Re: [jira] Resolved: (AXIS2-304) InOnly MEP blocks the caller till the operation finishes.......
Posted by robert lazarski <ro...@gmail.com>.
Deepal, I'm trying to test a long fire and forget call with the latest svn
and I'm confused. What receiver goes in services.xml ? Before it was
RawXMLINOnlyMessageReceiver - is this now for sendRobust (which currently
throws unsupported operation)? I see a AsyncMessageReceiver that extends
AbstractInOutAsyncMessageReceiver - but its under modules/integration/test .
Robert
http://www.braziloutsource.com/
On 3/13/06, Deepal Jayasinghe (JIRA) <ji...@apache.org> wrote:
>
> [ http://issues.apache.org/jira/browse/AXIS2-304?page=all ]
>
> Deepal Jayasinghe resolved AXIS2-304:
> -------------------------------------
>
> Fix Version: 0.95
> Resolution: Fixed
>
> - Clien side is sloved with ServiceClinet.firAndForget()
> - In the server side , if you use Async message receiver then you are done
>
> > InOnly MEP blocks the caller till the operation finishes.......
> > ---------------------------------------------------------------
> >
> > Key: AXIS2-304
> > URL: http://issues.apache.org/jira/browse/AXIS2-304
> > Project: Apache Axis 2.0 (Axis2)
> > Type: Bug
> > Components: core
> > Reporter: Thilina Gunarathne
> > Fix For: 0.95
>
> >
> > The above behaviour of the InOnly MEP causes the long running activities
> to timeout + It's ruining the advantages behind one way messaging......
> > Quoting Dr.Sanjiva,
> > when we get a message after dispatch is finished we know the MEP. If the
> MEP is In-Only, then we should immediately hand over the delivery of the
> message to a thread and return the original thread
> > Related to the following threads in the Dev list,
> >
> http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2572316.html
> >
> http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2296180.html
> > Fixing this might help to overcome the following in User list,
> >
> http://www.opensubscriber.com/message/axis-user@ws.apache.org/2464960.html
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>
[jira] Resolved: (AXIS2-304) InOnly MEP blocks the caller till the
operation finishes.......
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-304?page=all ]
Deepal Jayasinghe resolved AXIS2-304:
-------------------------------------
Fix Version: 0.95
Resolution: Fixed
- Clien side is sloved with ServiceClinet.firAndForget()
- In the server side , if you use Async message receiver then you are done
> InOnly MEP blocks the caller till the operation finishes.......
> ---------------------------------------------------------------
>
> Key: AXIS2-304
> URL: http://issues.apache.org/jira/browse/AXIS2-304
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Components: core
> Reporter: Thilina Gunarathne
> Fix For: 0.95
>
> The above behaviour of the InOnly MEP causes the long running activities to timeout + It's ruining the advantages behind one way messaging......
> Quoting Dr.Sanjiva,
> when we get a message after dispatch is finished we know the MEP. If the MEP is In-Only, then we should immediately hand over the delivery of the message to a thread and return the original thread
> Related to the following threads in the Dev list,
> http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2572316.html
> http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2296180.html
> Fixing this might help to overcome the following in User list,
> http://www.opensubscriber.com/message/axis-user@ws.apache.org/2464960.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS2-304) InOnly MEP blocks the caller till the operation finishes.......
Posted by "Thilina Gunarathne (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-304?page=comments#action_12357705 ]
Thilina Gunarathne commented on AXIS2-304:
------------------------------------------
A bit of thinking on to this issue gave me the following ideas.....
1. We need a MessageSender(MessageSender handles Robust OutOnly) counterpart which will handle the OutOnly MEP from the client side.... So that we can use that for Asynchronous two channel invocations....
2. We need a InOnlyMepClient (May be we should rename this to RobustInOnly....) counterpart on the server side which will handle the InOnly MEP....So that we can use that for one way messaging scenerios. This should work fine even when the client is using a RobustOutOnly Mep.....
3. A suggestion :: Can we release the calling thread in all cases when the incoming message has a replyTo EPR....
Pls comment..
> InOnly MEP blocks the caller till the operation finishes.......
> ---------------------------------------------------------------
>
> Key: AXIS2-304
> URL: http://issues.apache.org/jira/browse/AXIS2-304
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Components: core
> Reporter: Thilina Gunarathne
>
> The above behaviour of the InOnly MEP causes the long running activities to timeout + It's ruining the advantages behind one way messaging......
> Quoting Dr.Sanjiva,
> when we get a message after dispatch is finished we know the MEP. If the MEP is In-Only, then we should immediately hand over the delivery of the message to a thread and return the original thread
> Related to the following threads in the Dev list,
> http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2572316.html
> http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2296180.html
> Fixing this might help to overcome the following in User list,
> http://www.opensubscriber.com/message/axis-user@ws.apache.org/2464960.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS2-304) InOnly MEP blocks the caller till the operation finishes.......
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-304?page=comments#action_12357712 ]
Davanum Srinivas commented on AXIS2-304:
----------------------------------------
can the "robust"-ness can be a parameter in either the xml files and/or the message context parameters?
> InOnly MEP blocks the caller till the operation finishes.......
> ---------------------------------------------------------------
>
> Key: AXIS2-304
> URL: http://issues.apache.org/jira/browse/AXIS2-304
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Components: core
> Reporter: Thilina Gunarathne
>
> The above behaviour of the InOnly MEP causes the long running activities to timeout + It's ruining the advantages behind one way messaging......
> Quoting Dr.Sanjiva,
> when we get a message after dispatch is finished we know the MEP. If the MEP is In-Only, then we should immediately hand over the delivery of the message to a thread and return the original thread
> Related to the following threads in the Dev list,
> http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2572316.html
> http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2296180.html
> Fixing this might help to overcome the following in User list,
> http://www.opensubscriber.com/message/axis-user@ws.apache.org/2464960.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira