ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sathwik B P <sathwik...@gmail.com>
Subject Re: Same message correlating to multiple instances
Date Thu, 30 Jan 2014 16:50:03 GMT
Hi Nandika,

I wouldn't suggest to change the BpelRuntimeContextImpl.matcherEvent with
respect to the DAO, as we have Hibernate and Openjpa implementations.

Can you verify the behaviour with hibernate?

Will see if I get sometime over the weekend to look into this issue


On Mon, Jan 27, 2014 at 12:25 PM, Nandika Jayawardana <jayawark@gmail.com>wrote:

> Hi Devs,
> I observed the following behavior.
> Consider a process with two receive activities with correlation. Now, if
> the messages to these receive activities arrive in correct order,
> everything works fine.
> But if the message to the second receive activity arrived first and then
> the message to the first receive activity arrived, then the process would
> execute and complete. However, the message exchange created for the second
> message would not be updated. It would have the correlation set value and
> status as QUEUED.
> Now if another message arrived with the same correlation value for the
> first request, that process instance would also complete by correlating to
> the original second message.
> I  found that in BpelRuntimeContextImpl.matcherEvent, there is a call to
> release these mex as follows.
> // Do not release yet if the process is suspended, the mex will be used
> again
>    if (_dao.getState() != ProcessState.STATE_SUSPENDED){
>                 mexdao.releasePremieMessages();
>    }
> However, openjpa implementation for releasePremieMessages() is empty.
> Adding mexdao.release(true); to above if block fixes the problem.
> Is this the correct way to solve this problem.
> I checked whether there is a method to remove the correlation set from
> message exchange and update the status to MATCHED. However, could not find
> a method to update the correlation set value in message exchange.
> Attached is a sample process to reproduce the issue.
> Thanks
> Nandika

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message