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
>