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

Nested fork/join with inner join having multiplicity=1 does not work as expected in 4.4

    XMLWordPrintable

Details

    • Bug
    • Resolution: Unresolved
    • Major
    • jBPM 4.x
    • jBPM 4.4
    • Runtime Engine
    • Hide

      (1) Deploy a new process using the JPDL above.
      (2) Begin execution of the process
      (3) Complete either task1 or task2
      (4) Check the state of the process instance or list tasks for the process instance. Observe that the process instance is complete and no tasks are active. This is contrary to the expected behavior, which would be that task3 is still active.

      JUNIT TEST CODE:

      
          @Test
          public void TestJoinBug() {
              ProcessEngine processEngine = Configuration.getProcessEngine();
              RepositoryService repService = processEngine.getRepositoryService();
              ExecutionService executionService = processEngine.getExecutionService();
              org.jbpm.api.TaskService taskService = processEngine.getTaskService();
      
              NewDeployment newDeployment = repService.createDeployment();
              newDeployment.addResourceFromClasspath("join-issue.jpdl.xml");
              String deploymentId = newDeployment.deploy();    
              ProcessInstance processInstance = executionService.startProcessInstanceByKey("join_test");
      
              // tasks 1,2 and 3 are all active
      
              List<Task> tasks = taskService.createTaskQuery().processInstanceId(processInstance.getId()).list();
              assertEquals(3, tasks.size());
      
              Task task1 = taskService.createTaskQuery().activityName("task1").uniqueResult();
              assertNotNull(task1);
      
              Task task2 = taskService.createTaskQuery().activityName("task2").uniqueResult();
              assertNotNull(task2);
      
              Task task3 = taskService.createTaskQuery().activityName("task3").uniqueResult();
              assertNotNull(task3);
      
              // complete task 1
              taskService.completeTask(task1.getId());
      
              tasks = taskService.createTaskQuery().processInstanceId(processInstance.getId()).list();
      
              // task3 should be still active, but it is not
              // ** TEST FAILS HERE -- the process is now complete and no tasks are active **
              assertEquals(1, tasks.size());
      
          }
      
      
      Show
      (1) Deploy a new process using the JPDL above. (2) Begin execution of the process (3) Complete either task1 or task2 (4) Check the state of the process instance or list tasks for the process instance. Observe that the process instance is complete and no tasks are active. This is contrary to the expected behavior, which would be that task3 is still active. JUNIT TEST CODE: @Test public void TestJoinBug() { ProcessEngine processEngine = Configuration.getProcessEngine(); RepositoryService repService = processEngine.getRepositoryService(); ExecutionService executionService = processEngine.getExecutionService(); org.jbpm.api.TaskService taskService = processEngine.getTaskService(); NewDeployment newDeployment = repService.createDeployment(); newDeployment.addResourceFromClasspath( "join-issue.jpdl.xml" ); String deploymentId = newDeployment.deploy(); ProcessInstance processInstance = executionService.startProcessInstanceByKey( "join_test" ); // tasks 1,2 and 3 are all active List<Task> tasks = taskService.createTaskQuery().processInstanceId(processInstance.getId()).list(); assertEquals(3, tasks.size()); Task task1 = taskService.createTaskQuery().activityName( "task1" ).uniqueResult(); assertNotNull(task1); Task task2 = taskService.createTaskQuery().activityName( "task2" ).uniqueResult(); assertNotNull(task2); Task task3 = taskService.createTaskQuery().activityName( "task3" ).uniqueResult(); assertNotNull(task3); // complete task 1 taskService.completeTask(task1.getId()); tasks = taskService.createTaskQuery().processInstanceId(processInstance.getId()).list(); // task3 should be still active, but it is not // ** TEST FAILS HERE -- the process is now complete and no tasks are active ** assertEquals(1, tasks.size()); }

    Description

      The intent of the JPDL below is to model a workflow in which EITHER task1 OR task2, AND task3 must be completed, in any order.

      When the workflow starts, task1, task2 and task3 are all active, as expected. If I complete task3 first, then the workflow waits for me to complete either task1 or task2, and then completes. This works as expected.

      If I first complete either task1 or task2, the expected behavior is that the execution should be waiting for completion of task3. However, the observed behavior is that the workflow completes as soon as either task1 or task2 is completed, without waiting for task3.

      Workflow JPDL:

      <process key="join_test" name="join_test" xmlns="http://jbpm.org/4.4/jpdl">
         <start name="start">
            <transition to="fork1"/>
         </start>  
         <fork name="fork1">
            <transition to="fork2"/>
            <transition to="task3"/>
         </fork>  
         <fork name="fork2">
            <transition to="task1"/>
            <transition to="task2"/>
         </fork>  
         <task name="task1">
            <transition to="join1"/>
         </task>    
         <task name="task2">
            <transition to="join1"/>
         </task>     
         <task name="task3">
            <transition to="join2"/>
         </task>     
         <join name="join1" multiplicity="1">
            <transition to="join2" />
         </join> 
         <join name="join2">
            <transition to="end"/>
         </join> 
         <end name="end"/>  
      </process>
      

      Attachments

        Activity

          People

            Unassigned Unassigned
            jkranes@mitre.org Jon Kranes (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated: