ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sathwik Bantwal Premakumar (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ODE-974) On process versioning, instances of retired version are not picking the data from BPEL_UNMATCHED
Date Wed, 24 Feb 2016 13:59:18 GMT

    [ 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/24/16 1:58 PM:
-------------------------------------------------------------------------

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. If no process instance were to be identified then the mex will be registered
for the Active Process and picked up by the instance that would be created in future.


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.

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)

Mime
View raw message