[jbpm-issues] [JBoss JIRA] Commented: (JBPM-2754) Execution lost when using nested forks/parallel gateways

Joram Barrez (JIRA) jira-events at lists.jboss.org
Wed Jan 13 16:49:30 EST 2010


    [ https://jira.jboss.org/jira/browse/JBPM-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12505323#action_12505323 ] 

Joram Barrez commented on JBPM-2754:
------------------------------------

See nested_parallel_gateway_problem_2.jpg for the problem process (flipping the process vertically makes it work).

(neglect nested_parallel_gateway_problem?png ... image got somewhere srewed up).

> Execution lost when using nested forks/parallel gateways 
> ---------------------------------------------------------
>
>                 Key: JBPM-2754
>                 URL: https://jira.jboss.org/jira/browse/JBPM-2754
>             Project: jBPM
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Joram Barrez
>            Assignee: Tom Baeyens
>             Fix For: jBPM 4.x
>
>         Attachments: nested_parallel_gateway_problem.jpg, nested_parallel_gateway_problem_2.jpg
>
>
> Using nested forks and automatic activities causes an execution to be 'lost':
> Take the following example:
> start --> fork  ->  autom act. -> inner join 
>                      -> autom act. -> inner join  --> outer join
>                      -> wait stat -> outer join
> When the first autom act. is finished, the execution arrives in the inner join.
> When the second autom act is finished, the second execution arrives in the inner join
> Following code is executed (in the Join):
>   ExecutionImpl outgoingExecution = null;
>       if (concurrentRoot.getExecutions().size() == 0) {
>         outgoingExecution = concurrentRoot;
>         outgoingExecution.setState(Execution.STATE_ACTIVE_ROOT);
>       } else {
>         outgoingExecution = concurrentRoot.createExecution();
>         outgoingExecution.setState(Execution.STATE_ACTIVE_CONCURRENT);
>       }
> The first if will be taken. BUT conceptually the else clause should be taken. The problem is here that concurrentRoot.getExecutions.size() is 0, because the execution going to the wait state isn't created yet.
> So for this process, you could make it work by putting the transition toi the wait state first, and the other transitions to the inner join afterwards. That way, when the inner join is handled, the child execution exists and the else clause will be taken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the jbpm-issues mailing list