Uploaded image for project: 'jBPM'
  1. jBPM
  2. JBPM-1906

Inconsistent behaviour depending on the ordering of events (fork+end state+join)

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Major Major
    • None
    • jBPM 3.2.3
    • Runtime Engine
    • None

      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.

            tdiesler@redhat.com Thomas Diesler
            mauromol_jira Mauro Molinari (Inactive)
            Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: