[
https://issues.apache.org/jira/browse/ODE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15108563#comment-15108563
]
Sathwik Bantwal Premakumar edited comment on ODE-974 at 2/17/16 10:40 AM:
--------------------------------------------------------------------------
The fix works in this manner,
* Iterate over all versions of the process to find the route for the incoming
mex.
* When no route was identified, (probably an early mex).
** Previous behavior was to register the early mex with the active version of
the process. Hence the instance of the retired process which was awaiting will
not read the mex.
** New behavior is to, iterate over all the versions of the process to find the
process instance that is awaiting on the correlated value and enqueue the mex
for later processing with the right process version.
The assumption of this solution is that the process instance across multiple
versions of the same process is uniquely identifiable with the correlated value.
Example:
{code:xml}
<receive name="receive1" createInstance="yes" ....>
<bpel:correlations>
<bpel:correlation set="CorrelationSet1"
initiate="yes"></bpel:correlation
</bpel:correlations>
</receive>
<receive name="receive2"...>
<bpel:correlations>
<bpel:correlation set="CorrelationSet1"
initiate="no"></bpel:correlation>
<bpel:correlation set="CorrelationSet2"
initiate="yes"></bpel:correlation>
</bpel:correlations>
</receive>
<receive name="receive3"...>
<bpel:correlations>
<bpel:correlation set="CorrelationSet1"
initiate="no"></bpel:correlation>
<bpel:correlation set="CorrelationSet2"
initiate="no"></bpel:correlation>
</bpel:correlations>
</receive>
{code}
Receive1 is fired initially which creates the process instance, followed by
early message Receive3. In this case, value from the CorrelationSet1 will be
used to identify the process instance and associate it with the early arriving
mex Receive3. Hence, when the process gets the Receive2 message and proceeds
to process Receive3, the instance will be able to read the Recevie3 mex which
had already arrived.
was (Author: sathwik):
The fix works in this manner,
* Iterate over all versions of the process to find the route for the incoming
mex.
* When no route was identified, (probably an early mex).
** Previous behavior was to register the early mex with the active version of
the process. Hence the instance of the retired process which was awaiting will
not read the mex.
** New behavior is to, iterate over all the versions of the process to find the
process instance that is awaiting on the correlated value and enqueue the mex
for later processing with the right process version.
The assumption of this solution is that the process instance across multiple
versions of the same process is uniquely identifiable with the correlated
value. In case, the IMA (PICK, Receive) is configured with multi correlation
set, the first correlation key that was initialised prior to this IMA will be
used to identify the process instance.
Example:
{code:xml}
<receive name="receive1" createInstance="yes" ....>
<bpel:correlations>
<bpel:correlation set="CorrelationSet1"
initiate="yes"></bpel:correlation
</bpel:correlations>
</receive>
<receive name="receive2"...>
<bpel:correlations>
<bpel:correlation set="CorrelationSet1"
initiate="no"></bpel:correlation>
<bpel:correlation set="CorrelationSet2"
initiate="yes"></bpel:correlation>
</bpel:correlations>
</receive>
<receive name="receive3"...>
<bpel:correlations>
<bpel:correlation set="CorrelationSet1"
initiate="no"></bpel:correlation>
<bpel:correlation set="CorrelationSet2"
initiate="no"></bpel:correlation>
</bpel:correlations>
</receive>
{code}
Receive1 is fired initially which creates the process instance, followed by
early message Receive3. In this case, value from the CorrelationSet1 will be
used to identify the process instance and associate it with the early arriving
mex Receive3. Hence, when the process gets the Receive2 message and proceeds
to process Receive3, the instance will be able to read the Recevie3 mex which
had already arrived.
> On process versioning, instances of retired version are not picking the data
> from BPEL_UNMATCHED
> ------------------------------------------------------------------------------------------------
>
> Key: ODE-974
> URL: https://issues.apache.org/jira/browse/ODE-974
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Reporter: Jayant Vaish
> Assignee: Sathwik Bantwal Premakumar
> Priority: Critical
> Fix For: 1.3.7, 1.4
>
> Attachments: ODE_974.zip, sample10534.zip
>
>
> If there is a process which receives the data from another process in such a
> manner that the data arrives first and then the instance reaches the activity
> which needs it, the instance picks the data from the BPEL_UNMATCHED table.
> If we deploy the process again, then the running instances of retired process
> are not picking data from BPEL_UNMATCHED hence not getting completed.
> I have attached the process. Here are the steps to reproduce :
> 1. Deploy the process. Start the parent process from console.
> 2. Deploy again.
> 3. After one min you will see that the child process has completed, and there
> is an entry in BPEL_UNMATCHED.
> 4. After two mins you will see that parent process is still waiting for the
> message from child process, which has already came and currently is in
> BPEL_UNMATCHED table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
