You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by Arkadiusz Burdach <ab...@touk.pl> on 2008/08/06 14:26:18 UTC
Re: FATAL in BpelRuntimeContextImpl
Hi.
I was on holiday so I didn't look on this bug, but now I'm back and will
continue works on it. Hope, you are happy about it :-)
After investigation of code and tests, I founded, that:
- MessageExchange is in state RESPONSE, because it is older MEX (belong
to one of previous instances of process)
- matcherEvent take this MEX, because value of correlation key is older
- value of correlation key is older because correlation key is
initialized as older
- value of correlation key is initialized as older because two instances
of process got the same message
I've checked this by pmapi and it's true. Two processes stay in state
active and got the same input message.
Some tips why it is done? I remind that problem exists with JBI IL and
WEB IL.
Maybe somebody can tell me, how looks way delivering message to process?
Cheers, Arek
Re: FATAL in BpelRuntimeContextImpl
Posted by Arkadiusz Burdach <ab...@touk.pl>.
Matthieu Riou wrote:
> You mean that you're sending twice the same message
Ok, I got it. Problem is not in ode but in my testing script, I'm
closing bug and apologizing for my fault ;-)
Arek
Re: FATAL in BpelRuntimeContextImpl
Posted by Arkadiusz Burdach <ab...@touk.pl>.
Matthieu Riou wrote:
> On Wed, Aug 6, 2008 at 5:26 AM, Arkadiusz Burdach <ab...@touk.pl> wrote:
>
>
>> Hi.
>>
>> I was on holiday so I didn't look on this bug, but now I'm back and will
>> continue works on it. Hope, you are happy about it :-)
>> After investigation of code and tests, I founded, that:
>>
>> - MessageExchange is in state RESPONSE, because it is older MEX (belong to
>> one of previous instances of process)
>> - matcherEvent take this MEX, because value of correlation key is older
>> - value of correlation key is older because correlation key is initialized
>> as older
>> - value of correlation key is initialized as older because two instances of
>> process got the same message
>>
>> I've checked this by pmapi and it's true. Two processes stay in state
>> active and got the same input message.
>>
>> Some tips why it is done? I remind that problem exists with JBI IL and WEB
>> IL.
>> Maybe somebody can tell me, how looks way delivering message to process?
>>
>>
>
> You mean that you're sending twice the same message, resulting in two
> processes with the same correlation? We're actually still missing the check
> for this and should throw a bpel:correlationViolation.
>
No, I'm sending two diffrent messages (with diffrent correlation key
e.g. <id>1</id> and <id>2</id>) but in pmapi I can see that two
instances of process have in variable the same id.
Arek
Re: FATAL in BpelRuntimeContextImpl
Posted by Matthieu Riou <ma...@offthelip.org>.
On Wed, Aug 6, 2008 at 5:26 AM, Arkadiusz Burdach <ab...@touk.pl> wrote:
> Hi.
>
> I was on holiday so I didn't look on this bug, but now I'm back and will
> continue works on it. Hope, you are happy about it :-)
> After investigation of code and tests, I founded, that:
>
> - MessageExchange is in state RESPONSE, because it is older MEX (belong to
> one of previous instances of process)
> - matcherEvent take this MEX, because value of correlation key is older
> - value of correlation key is older because correlation key is initialized
> as older
> - value of correlation key is initialized as older because two instances of
> process got the same message
>
> I've checked this by pmapi and it's true. Two processes stay in state
> active and got the same input message.
>
> Some tips why it is done? I remind that problem exists with JBI IL and WEB
> IL.
> Maybe somebody can tell me, how looks way delivering message to process?
>
You mean that you're sending twice the same message, resulting in two
processes with the same correlation? We're actually still missing the check
for this and should throw a bpel:correlationViolation.
Matthieu
>
> Cheers, Arek
>