axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thilina Gunarathne <cset...@gmail.com>
Subject Re: [Axis2] Message Sender blocks the caller...
Date Tue, 15 Nov 2005 13:15:04 GMT
Jira issue created..
http://issues.apache.org/jira/browse/AXIS2-304
 Thanks,
~Thilina

 On 11/15/05, trebor iksrazal <iksrazal@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 <sanjiva@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

Mime
View raw message