[jbpm-issues] [JBoss JIRA] Commented: (JBPM-1906) Inconsistent behaviour depending on the ordering of events (fork+end state+join)

From the processdefintion image and a quick scan of the tests (and text), jBPM is behaving is it was intended to. All tokens that are generated in a fork should go to the join before it is reactivated... completely as designed. I totally miss the reason for the two other tokens to end and not go to the join. The join is only activated once, so tokens do not have to 'die' somewhere....

Inconsistent behaviour depending on the ordering of events (fork+end state+join) -------------------------------------------------------------------------------- Key: JBPM-1906 URL: https://jira.jboss.org/jira/browse/JBPM-1906 Project: JBoss jBPM Issue Type: Bug Security Level: Public(Everyone can see) Components: Core Engine Affects Versions: jBPM 3.2.3 Reporter: Mauro Molinari Priority: Critical Fix For: jBPM 3.3.2 GA Attachments: Test bug JBPM-1906.zip Given the following process definition: <?xml version="1.0" encoding="UTF-8"?> <process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="Complex"> <description> Complex description </description> <start-state name="start-state1"> <transition to="task-node1"></transition> </start-state> <task-node name="task-node3"> <task name="Task3_1"> <assignment actor-id="1"></assignment> </task> <transition to="end-state1"></transition> </task-node> <node name="node1"> <transition to="task-node3"></transition> </node> <join name="join1"> <transition to="node1"></transition> </join> <fork name="fork1"> <transition to="task-node2"></transition> <transition to="node2" name="to node2"></transition> <transition to="state1" name="to state1"></transition> </fork> <task-node name="task-node2"> <task name="Task2_1"> <assignment actor-id="1"></assignment> </task> <task name="Task2_2"> <assignment actor-id="1"></assignment> </task> <transition to="join1"></transition> </task-node> <task-node name="task-node1"> <task name="Task1_1"> <assignment actor-id="1"></assignment> </task> <transition to="fork1"></transition> </task-node> <node name="node2"> <transition to="end-state2"></transition> </node> <state name="state1"> <transition to="end-state2"></transition> </state> <end-state name="end-state1"></end-state> <end-state name="end-state2"></end-state> </process-definition> Try to do this: - create a process instance and start it - a Task1_1 instance is created: end it - the root token halts at the fork and three children tokens are created 1) the first causes the creation of a Task2_1 instance and of a Task2_2 instance 2) the second halts at the state1 state 3) the third dies at the end-state2 state Now, there are two cases: CASE A) - signal the second token: it then goes on and dies at end-state2 state - end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join - now, the root token is restored and goes through node1 and task-node3 nodes, causing the creation of a Task3_1 instance This is what I would expect! CASE B) - end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join - signal the second token: it then goes on and dies at end-state2 state - now, the root token is ended, halting the process instance! This is not the expected behaviour, as I would expect that the root token is restored because now all the sibling tokens of those that have reached the join node are ended, so the parent token (= the root token) should be restored and should continue to node1 and subsequent nodes. Moreover, I would not expect that the behaviour is different depending on the ordering of the actions "signal the state1 token" and "signal the task-node2 token". My suspect is this: in case B) the join node is not "triggered" anymore after Task2_1 and Task2_2 are ended, so it can't restore the parent node. Moreover, when the second children token is signalled, it reaches end-state2: jBPM then realizes that all of the sibling tokens are also ended, so it wrongly decides that the parent token should also be ended.