You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by Rafal Rusin <ra...@gmail.com> on 2009/03/13 13:40:13 UTC
Question about handling in-out operations
I have a following process:
<receive1 operation1 correlationSet1/>
<reply1/>
<wait 10min./>
<receive2 operation2 correlationSet1/>
<reply2/>
When I send a message for operation2 during wait, I get timeout.
Shouldn't it be some fault exception like "no such operation" without
any delay instead?
I'm attaching an example with soapUI test case.
Regards,
--
Rafał Rusin
http://www.touk.pl
http://www.mimuw.edu.pl/~rrusin
Re: Question about handling in-out operations
Posted by Alex Boisvert <bo...@intalio.com>.
Can you file an issue for the NPE? It shouldn't happen.
On Fri, Mar 13, 2009 at 5:57 AM, Rafal Rusin <ra...@gmail.com> wrote:
> Also, when I set a wait to 10sec. and launch a test, I get
> NullPointerException (like in attachment) while using tomcat axis
> version.
>
> 2009/3/13 Rafal Rusin <ra...@gmail.com>:
> > I have a following process:
> > <receive1 operation1 correlationSet1/>
> > <reply1/>
> > <wait 10min./>
> > <receive2 operation2 correlationSet1/>
> > <reply2/>
> >
> > When I send a message for operation2 during wait, I get timeout.
> > Shouldn't it be some fault exception like "no such operation" without
> > any delay instead?
> >
> > I'm attaching an example with soapUI test case.
> >
> > Regards,
> > --
> > Rafał Rusin
> > http://www.touk.pl
> > http://www.mimuw.edu.pl/~rrusin <http://www.mimuw.edu.pl/%7Errusin>
> >
>
>
>
> --
> Rafał Rusin
> http://www.touk.pl
> http://www.mimuw.edu.pl/~rrusin <http://www.mimuw.edu.pl/%7Errusin>
>
Re: Question about handling in-out operations
Posted by Rafal Rusin <ra...@gmail.com>.
Also, when I set a wait to 10sec. and launch a test, I get
NullPointerException (like in attachment) while using tomcat axis
version.
2009/3/13 Rafal Rusin <ra...@gmail.com>:
> I have a following process:
> <receive1 operation1 correlationSet1/>
> <reply1/>
> <wait 10min./>
> <receive2 operation2 correlationSet1/>
> <reply2/>
>
> When I send a message for operation2 during wait, I get timeout.
> Shouldn't it be some fault exception like "no such operation" without
> any delay instead?
>
> I'm attaching an example with soapUI test case.
>
> Regards,
> --
> Rafał Rusin
> http://www.touk.pl
> http://www.mimuw.edu.pl/~rrusin
>
--
Rafał Rusin
http://www.touk.pl
http://www.mimuw.edu.pl/~rrusin
Re: Question about handling in-out operations
Posted by Rafal Rusin <ra...@gmail.com>.
OK, I reported this issue and a previous NPE too.
--
Rafał Rusin
http://www.touk.pl
http://www.mimuw.edu.pl/~rrusin
Re: Question about handling in-out operations
Posted by Rafal Rusin <ra...@gmail.com>.
Not yet. So I'll do this.
2009/3/17 Matthieu Riou <ma...@gmail.com>:
> Have you created a Jira issue for this patch?
>
> Thanks,
> Matthieu
>
> On Mon, Mar 16, 2009 at 4:34 AM, Rafal Rusin <ra...@gmail.com> wrote:
>
>> 2009/3/13 Assaf Arkin <ar...@intalio.com>:
>> > When doing request/response with SOAP over HTTP, the quality of service
>> > guarantee is that of HTTP, which doesn't allow requests to be held
>> > indefinitely, so Ode should reject the request if it can't service the
>> > operation quickly enough.
>> >
>> > If this was one-way over asynchronous transport, queuing the message and
>> > handling it 10 minutes later would be the correct approach.
>>
>> Yes, this is how I see it too.
>> So I did a patch for handling in-out operations quickly for ODE1X. It
>> was partly implemented before.
>> In-only operations are queued as before.
>>
>> It works like this: when ODE doesn't find routing for a given in-out
>> request, it replies with failure.
>>
>> Regards,
>> --
>> Rafał Rusin
>> http://www.touk.pl
>> http://www.mimuw.edu.pl/~rrusin <http://www.mimuw.edu.pl/%7Errusin>
>>
>
--
Rafał Rusin
http://www.touk.pl
http://www.mimuw.edu.pl/~rrusin
Re: Question about handling in-out operations
Posted by Matthieu Riou <ma...@gmail.com>.
Have you created a Jira issue for this patch?
Thanks,
Matthieu
On Mon, Mar 16, 2009 at 4:34 AM, Rafal Rusin <ra...@gmail.com> wrote:
> 2009/3/13 Assaf Arkin <ar...@intalio.com>:
> > When doing request/response with SOAP over HTTP, the quality of service
> > guarantee is that of HTTP, which doesn't allow requests to be held
> > indefinitely, so Ode should reject the request if it can't service the
> > operation quickly enough.
> >
> > If this was one-way over asynchronous transport, queuing the message and
> > handling it 10 minutes later would be the correct approach.
>
> Yes, this is how I see it too.
> So I did a patch for handling in-out operations quickly for ODE1X. It
> was partly implemented before.
> In-only operations are queued as before.
>
> It works like this: when ODE doesn't find routing for a given in-out
> request, it replies with failure.
>
> Regards,
> --
> Rafał Rusin
> http://www.touk.pl
> http://www.mimuw.edu.pl/~rrusin <http://www.mimuw.edu.pl/%7Errusin>
>
Re: Question about handling in-out operations
Posted by Rafal Rusin <ra...@gmail.com>.
2009/3/13 Assaf Arkin <ar...@intalio.com>:
> When doing request/response with SOAP over HTTP, the quality of service
> guarantee is that of HTTP, which doesn't allow requests to be held
> indefinitely, so Ode should reject the request if it can't service the
> operation quickly enough.
>
> If this was one-way over asynchronous transport, queuing the message and
> handling it 10 minutes later would be the correct approach.
Yes, this is how I see it too.
So I did a patch for handling in-out operations quickly for ODE1X. It
was partly implemented before.
In-only operations are queued as before.
It works like this: when ODE doesn't find routing for a given in-out
request, it replies with failure.
Regards,
--
Rafał Rusin
http://www.touk.pl
http://www.mimuw.edu.pl/~rrusin
Re: Question about handling in-out operations
Posted by Assaf Arkin <ar...@intalio.com>.
2009/3/13 Andi Abes <aa...@progress.com>
> The BPEL spec demands of engines to handle messages received by them before
> the corresponding receive activity has executed.
> This makes sense since it avoids various race conditions and
> inconsistencies among diff bpel engines (see quote below).
>
> As such, ODE is correct in holding the message pending, until the receive
> activity is activated.
> Potentially a better modeling approach would be to use a pick activity and
> an onAlarm as a means to implement the 10 minute timeout.
> An alternative could be to event handlers in scope containing the <wait>
> sop you can process the incoming message (even if only to reject it using
> some application error).
>
>
> Quote from p.92 of BPEL spec:
>
> Race conditions may occur in a business process execution. Messages that
> target a particular process instance may arrive before the corresponding
> <receive> activity is started. For example, consider a process that receives
> a series of messages in a loop where all the messages use the same
> correlation. At runtime, the messages will arrive independent of the
> iterations of the loop. The fact that the correlation is already initiated,
> however, should enable the runtime engine and messaging platform to
> recognize that these messages are correlated to the process instance, and
> handle those messages appropriately. Another example is a process that may
> invoke a remote service then initiate a correlation set for an expected
> callback message. For a variety of reasons, the callback message may arrive
> before the corresponding <receive> activity is started.
>
The remainder of the paragraph:
The correlation data in the arriving message should enable the engine
to recognize that the message is targeted for this process instance.
Process engines MAY employ different mechanisms to handle such race
conditions. This specification does not mandate any specific
mechanism. Details of message delivery mechanisms are outside of the
scope of this specification. However, a WS-BPEL processor should
deliver messages to the process instance according to the quality of
service of the underlying message delivery and transport mechanisms.
For the purposes of handling race conditions, an <onMessage> clause in
a <pick> and an <onEvent> event handler are equivalent to a receive
(see sections 11.5. Selective Event Processing - Pick and 12.7.1.
Message Events).
When doing request/response with SOAP over HTTP, the quality of service
guarantee is that of HTTP, which doesn't allow requests to be held
indefinitely, so Ode should reject the request if it can't service the
operation quickly enough.
If this was one-way over asynchronous transport, queuing the message and
handling it 10 minutes later would be the correct approach.
Assaf
>
>
>
> > -----Original Message-----
> > From: Rafal Rusin [mailto:rafal.rusin@gmail.com]
> > Sent: Friday, March 13, 2009 8:40 AM
> > To: user@ode.apache.org
> > Subject: Question about handling in-out operations
> >
> > I have a following process:
> > <receive1 operation1 correlationSet1/>
> > <reply1/>
> > <wait 10min./>
> > <receive2 operation2 correlationSet1/>
> > <reply2/>
> >
> > When I send a message for operation2 during wait, I get timeout.
> > Shouldn't it be some fault exception like "no such operation" without
> > any delay instead?
> >
> > I'm attaching an example with soapUI test case.
> >
> > Regards,
> > --
> > Rafał Rusin
> > http://www.touk.pl
> > http://www.mimuw.edu.pl/~rrusin
>
RE: Question about handling in-out operations
Posted by Andi Abes <aa...@progress.com>.
The BPEL spec demands of engines to handle messages received by them before the corresponding receive activity has executed.
This makes sense since it avoids various race conditions and inconsistencies among diff bpel engines (see quote below).
As such, ODE is correct in holding the message pending, until the receive activity is activated.
Potentially a better modeling approach would be to use a pick activity and an onAlarm as a means to implement the 10 minute timeout.
An alternative could be to event handlers in scope containing the <wait> sop you can process the incoming message (even if only to reject it using some application error).
Quote from p.92 of BPEL spec:
Race conditions may occur in a business process execution. Messages that target a particular process instance may arrive before the corresponding <receive> activity is started. For example, consider a process that receives a series of messages in a loop where all the messages use the same correlation. At runtime, the messages will arrive independent of the iterations of the loop. The fact that the correlation is already initiated, however, should enable the runtime engine and messaging platform to recognize that these messages are correlated to the process instance, and handle those messages appropriately. Another example is a process that may invoke a remote service then initiate a correlation set for an expected callback message. For a variety of reasons, the callback message may arrive before the corresponding <receive> activity is started.
> -----Original Message-----
> From: Rafal Rusin [mailto:rafal.rusin@gmail.com]
> Sent: Friday, March 13, 2009 8:40 AM
> To: user@ode.apache.org
> Subject: Question about handling in-out operations
>
> I have a following process:
> <receive1 operation1 correlationSet1/>
> <reply1/>
> <wait 10min./>
> <receive2 operation2 correlationSet1/>
> <reply2/>
>
> When I send a message for operation2 during wait, I get timeout.
> Shouldn't it be some fault exception like "no such operation" without
> any delay instead?
>
> I'm attaching an example with soapUI test case.
>
> Regards,
> --
> Rafał Rusin
> http://www.touk.pl
> http://www.mimuw.edu.pl/~rrusin
Re: Question about handling in-out operations
Posted by Alex Boisvert <bo...@intalio.com>.
I agree we should provide better error reporting for the client... there are
actually different possible causes,
1) operation not currently available
2) operation timed out (meaning, message was picked up but reply didn't
come)
3) process failed during operation
I suggest filing an enhancement request.
alex
On Fri, Mar 13, 2009 at 5:40 AM, Rafal Rusin <ra...@gmail.com> wrote:
> I have a following process:
> <receive1 operation1 correlationSet1/>
> <reply1/>
> <wait 10min./>
> <receive2 operation2 correlationSet1/>
> <reply2/>
>
> When I send a message for operation2 during wait, I get timeout.
> Shouldn't it be some fault exception like "no such operation" without
> any delay instead?
>
> I'm attaching an example with soapUI test case.
>
> Regards,
> --
> Rafał Rusin
> http://www.touk.pl
> http://www.mimuw.edu.pl/~rrusin <http://www.mimuw.edu.pl/%7Errusin>
>