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 <cs...@gmail.com> on 2005/11/14 13:34:23 UTC
[Axis2] Message Sender blocks the caller...
Hi all,
This message is related to the following unanswered question on the Dev
list......
http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2296180.html
And I feel this is the very reason for the,
http://www.opensubscriber.com/message/axis-user@ws.apache.org/2464960.html
According to what I can understand we have a "Robust-In" behaviour in the
message sender. Is this the expected behaviour of message sender...
But when it comes to One-Way messaging, which we use extensively in
Kandula2, I feel like we should use a "fire and forget" style.. If not the
sender has to wait till the whole operation is finished on the server side.
The other solution came to my mind is to create a separate thread in the
server side to carry out the operation when it is called so that we can
release the calling thread allowing it to return a 200 OK....
Which approach is the better one ... How we can get the support from Axis2
if we are going to use the "fire and forget" approach...
IMO this Robust-In is the culprit for the above user list problem...Since we
use message sender underneath to do the asynchronous two channel
invocation..It waits till it gets a 200OK... So that eventually it'll time
out...
Thanks & Regards,
~Thilina
--
"May the SourcE be with u"
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
http://www.bloglines.com/blog/Thilina
Re: [Axis2] Message Sender blocks the caller...
Posted by Thilina Gunarathne <cs...@gmail.com>.
Jira issue created..
http://issues.apache.org/jira/browse/AXIS2-304
Thanks,
~Thilina
On 11/15/05, trebor iksrazal <ik...@yahoo.com> wrote:
>
> Question: Is there currently _any_ way that a client
> can get an immediate return of http 200 ? I have a
> long running task on the server side - 6 to 20
> minutes. I've tried MessageSender and
> call.invokeNonBlocking with a Callback and
> call.setTransport(Constants.TRANSPORT_HTTP,Constants.TRANSPORT_HTTP,true)
> and they all timeout.
>
> I'm willing to help if needed.
>
> iksrazal
>
> --- Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> > Hi Thilina,
> >
> > > Hi all,
> > > This message is related to the following
> > unanswered question on the
> > > Dev list......
> > >
> >
> http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2296180.html
> > >
> > > And I feel this is the very reason for the,
> > >
> >
> http://www.opensubscriber.com/message/axis-user@ws.apache.org/2464960.html
> > >
> > > According to what I can understand we have a
> > "Robust-In" behaviour
> > > in the message sender. Is this the expected
> > behaviour of message
> > > sender...
> > > But when it comes to One-Way messaging, which we
> > use extensively in
> > > Kandula2, I feel like we should use a "fire and
> > forget" style.. If
> > > not the sender has to wait till the whole
> > operation is finished on the
> > > server side. The other solution came to my mind is
> > to create a
> > > separate thread in the server side to carry out
> > the operation when it
> > > is called so that we can release the calling
> > thread allowing it to
> > > return a 200 OK....
> > > Which approach is the better one ... How we can
> > get the support from
> > > Axis2 if we are going to use the "fire and forget"
> > approach...
> >
> > You're absolutely right .. what we support now is
> > Robust In-Only and not
> > In-Only (aka fire-and-forget).
> >
> > On the server-side, 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 (as that's the only way to wrap up a servlet
> > if that's the input
> > path).
> >
> > We could support fire-and-forget on the client too-
> > in that case, the
> > API can immediately return after handing the work
> > off to a separate
> > thread. That would have the effect of supporting
> > In-Only for "faulty"
> > server-side In-Only impls (like ours right now :-))
> > too.
> >
> > > IMO this Robust-In is the culprit for the above
> > user list
> > > problem...Since we use message sender underneath
> > to do the
> > > asynchronous two channel invocation..It waits till
> > it gets a 200OK...
> > > So that eventually it'll time out...
> >
> > +1.
> >
> > Can you please open a Jira with a ref to your email?
> >
> > Sanjiva.
> >
> >
> >
>
>
> "None are more hopelessly enslaved than those who falsely believe they are
> free. -- Goethe"
>
>
>
> __________________________________
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com
>
--
"May the SourcE be with u"
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/ http://www.bloglines.com/blog/Thilina
Re: [Axis2] Message Sender blocks the caller...
Posted by Eran Chinthaka <ch...@opensource.lk>.
Hi Trebor,
If you like to contribute we are more than happy to welcome you in. I
think you gonna implement In-Only MEP
<http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#in-only> (Fire
and Forget) and polish up Robust In-Only
<http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#robust-in-only>,
we have implemented.
So please create a JIRA on this and go ahead with the implementation. If
you need any help, just don't hesitate to ask it from this list.
Chinthaka
trebor iksrazal wrote:
>Question: Is there currently _any_ way that a client
>can get an immediate return of http 200 ? I have a
>long running task on the server side - 6 to 20
>minutes. I've tried MessageSender and
>call.invokeNonBlocking with a Callback and
>call.setTransport(Constants.TRANSPORT_HTTP,Constants.TRANSPORT_HTTP,true)
>and they all timeout.
>
>I'm willing to help if needed.
>
>iksrazal
>
>--- Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
>
>
>>Hi Thilina,
>>
>>
>>
>>>Hi all,
>>>This message is related to the following
>>>
>>>
>>unanswered question on the
>>
>>
>>>Dev list......
>>>
>>>
>>>
>http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2296180.html
>
>
>>>And I feel this is the very reason for the,
>>>
>>>
>>>
>http://www.opensubscriber.com/message/axis-user@ws.apache.org/2464960.html
>
>
>>>According to what I can understand we have a
>>>
>>>
>>"Robust-In" behaviour
>>
>>
>>>in the message sender. Is this the expected
>>>
>>>
>>behaviour of message
>>
>>
>>>sender...
>>>But when it comes to One-Way messaging, which we
>>>
>>>
>>use extensively in
>>
>>
>>>Kandula2, I feel like we should use a "fire and
>>>
>>>
>>forget" style.. If
>>
>>
>>>not the sender has to wait till the whole
>>>
>>>
>>operation is finished on the
>>
>>
>>>server side. The other solution came to my mind is
>>>
>>>
>>to create a
>>
>>
>>>separate thread in the server side to carry out
>>>
>>>
>>the operation when it
>>
>>
>>>is called so that we can release the calling
>>>
>>>
>>thread allowing it to
>>
>>
>>>return a 200 OK....
>>>Which approach is the better one ... How we can
>>>
>>>
>>get the support from
>>
>>
>>>Axis2 if we are going to use the "fire and forget"
>>>
>>>
>>approach...
>>
>>You're absolutely right .. what we support now is
>>Robust In-Only and not
>>In-Only (aka fire-and-forget).
>>
>>On the server-side, 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 (as that's the only way to wrap up a servlet
>>if that's the input
>>path).
>>
>>We could support fire-and-forget on the client too-
>>in that case, the
>>API can immediately return after handing the work
>>off to a separate
>>thread. That would have the effect of supporting
>>In-Only for "faulty"
>>server-side In-Only impls (like ours right now :-))
>>too.
>>
>>
>>
>>>IMO this Robust-In is the culprit for the above
>>>
>>>
>>user list
>>
>>
>>>problem...Since we use message sender underneath
>>>
>>>
>>to do the
>>
>>
>>>asynchronous two channel invocation..It waits till
>>>
>>>
>>it gets a 200OK...
>>
>>
>>>So that eventually it'll time out...
>>>
>>>
>>+1.
>>
>>Can you please open a Jira with a ref to your email?
>>
>>Sanjiva.
>>
>>
>>
>>
>>
>
>
>"None are more hopelessly enslaved than those who falsely believe they are free. -- Goethe"
>
>
>
>__________________________________
>Yahoo! FareChase: Search multiple travel sites in one click.
>http://farechase.yahoo.com
>
>
>
>
Re: [Axis2] Message Sender blocks the caller...
Posted by trebor iksrazal <ik...@yahoo.com>.
Question: Is there currently _any_ way that a client
can get an immediate return of http 200 ? I have a
long running task on the server side - 6 to 20
minutes. I've tried MessageSender and
call.invokeNonBlocking with a Callback and
call.setTransport(Constants.TRANSPORT_HTTP,Constants.TRANSPORT_HTTP,true)
and they all timeout.
I'm willing to help if needed.
iksrazal
--- Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> Hi Thilina,
>
> > Hi all,
> > This message is related to the following
> unanswered question on the
> > Dev list......
> >
>
http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2296180.html
> >
> > And I feel this is the very reason for the,
> >
>
http://www.opensubscriber.com/message/axis-user@ws.apache.org/2464960.html
> >
> > According to what I can understand we have a
> "Robust-In" behaviour
> > in the message sender. Is this the expected
> behaviour of message
> > sender...
> > But when it comes to One-Way messaging, which we
> use extensively in
> > Kandula2, I feel like we should use a "fire and
> forget" style.. If
> > not the sender has to wait till the whole
> operation is finished on the
> > server side. The other solution came to my mind is
> to create a
> > separate thread in the server side to carry out
> the operation when it
> > is called so that we can release the calling
> thread allowing it to
> > return a 200 OK....
> > Which approach is the better one ... How we can
> get the support from
> > Axis2 if we are going to use the "fire and forget"
> approach...
>
> You're absolutely right .. what we support now is
> Robust In-Only and not
> In-Only (aka fire-and-forget).
>
> On the server-side, 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 (as that's the only way to wrap up a servlet
> if that's the input
> path).
>
> We could support fire-and-forget on the client too-
> in that case, the
> API can immediately return after handing the work
> off to a separate
> thread. That would have the effect of supporting
> In-Only for "faulty"
> server-side In-Only impls (like ours right now :-))
> too.
>
> > IMO this Robust-In is the culprit for the above
> user list
> > problem...Since we use message sender underneath
> to do the
> > asynchronous two channel invocation..It waits till
> it gets a 200OK...
> > So that eventually it'll time out...
>
> +1.
>
> Can you please open a Jira with a ref to your email?
>
> Sanjiva.
>
>
>
"None are more hopelessly enslaved than those who falsely believe they are free. -- Goethe"
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
Re: [Axis2] Message Sender blocks the caller...
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Thilina,
> Hi all,
> This message is related to the following unanswered question on the
> Dev list......
> http://www.opensubscriber.com/message/axis-dev@ws.apache.org/2296180.html
>
> And I feel this is the very reason for the,
> http://www.opensubscriber.com/message/axis-user@ws.apache.org/2464960.html
>
> According to what I can understand we have a "Robust-In" behaviour
> in the message sender. Is this the expected behaviour of message
> sender...
> But when it comes to One-Way messaging, which we use extensively in
> Kandula2, I feel like we should use a "fire and forget" style.. If
> not the sender has to wait till the whole operation is finished on the
> server side. The other solution came to my mind is to create a
> separate thread in the server side to carry out the operation when it
> is called so that we can release the calling thread allowing it to
> return a 200 OK....
> Which approach is the better one ... How we can get the support from
> Axis2 if we are going to use the "fire and forget" approach...
You're absolutely right .. what we support now is Robust In-Only and not
In-Only (aka fire-and-forget).
On the server-side, 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 (as that's the only way to wrap up a servlet if that's the input
path).
We could support fire-and-forget on the client too- in that case, the
API can immediately return after handing the work off to a separate
thread. That would have the effect of supporting In-Only for "faulty"
server-side In-Only impls (like ours right now :-)) too.
> IMO this Robust-In is the culprit for the above user list
> problem...Since we use message sender underneath to do the
> asynchronous two channel invocation..It waits till it gets a 200OK...
> So that eventually it'll time out...
+1.
Can you please open a Jira with a ref to your email?
Sanjiva.