Strange behavior using JBPM 4.4 with nested fork/joins having a Multiplicity

[k0k0pelli]

We are currently using jBPM 4.4 (actually it's the unreleased revision 6879, as it contains a feature that is needed by our implementation) which is integrated in our own frameworks. I have a process definition with nested fork/joins. The joins have a multiplicity given. When I finish a nested fork/join (multiplicity=2), the parallel executions of the enclosing fork/join are also finished. See the example screenshots below.

Screenshot 1 shows the execution of the workflow before a nested fork/join is finished. This is actually done by completing the human Task PC Hard- / Software bestimmen (right-most task that is bordered with the color red) in the screenshot. After finishing this task, the nested fork/join is completed and the task Bestehende Hardware zum Neuaufsetzen bringen is selected correctly (the only red-bordered Task in screenshot 2). However, the other human tasks from the enclosing fork/join are completed, although they should not.

Is there something wrong with the modeling or is this a problem within jBPM 4.4 (unreleased revision 6879)? I found the Jira issue https://issues.jboss.org/browse/JBPM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel which may be related with this problem.

Any help is appreciated. Thanx.

Screenshot 1:

Screenshot 2:

[k0k0pelli]

Addendum: in the metnioned Jira ticket above, Ronald van Kuijk suggests to have an xml attribute end-concurrent which might activate the feature of deleting all other parallel executions in the case there is a multiplicity given. As far as I can see now, this flag would solve my problem. However, in the patch attached to the Jira ticket, I did not see this kind of implementation. Has this issue already been solved in the mean time?

[k0k0pelli]

As nobody answers, I'd like to illustrate the problem again with a simpler example as given above. The following example shows the above problem in asimplified way:

We have 2 fork/join elments that are nested. The outer fork/join(fork1/join1) contains task1 that is executed in parallel with the innerfork/join (fork2/join2). The inner fork join consists of task2 and task3, which are alternatives that are chosen by a decision (exclusive1). Task 4 executes in parallel to task2 or task3, depending on the alternative that is chosen. Because there are three transitions ending in the inner join activity (join2), a multiplicity must be specified, as otherwise the join does not go on with its execution.

However, with the current implementation of jBPM 4.4, depending on the way the workflow is executed, a strange behavior can be created.

Executing first task1, causes a normal execution, i.e., all tasks are executed as expected. However, finishing first the inner join activity (join2) leads to a strange behavior, which is probably due to the bug fix of described in https://issues.jboss.org/browse/JBPM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel. The bugfix in the mentioned Jira ticket terminates all executions that did not arrive in any join, but only if there is a multiplicity given in the completed join activity. However, it should just kill the non-finished executions that end in the join activity to be completed and not all (concurrent) executions.

Thus, if task2 or task3, respectively, and task4 are finished before task1,  the procedure completing the inner join activity (join2) deletes also the active exection of task1, even though this should not be the case. From my point of view, there are three possible solutions:

1. A flag for switching the kill mechanism off is introduced, as this was suggested in the above mentioned Jira ticket. However, I did not find anything like that in the implementation. This is maybe the simplest solution.
2. Running exections are aborted only iff they will end in the join that is going to be completed.
3. Remodeling the workflow using no nested join/forks. However, this solutions is not possible in every case.

Did anybodyencounter the same problems and is there a simpler solution than the ones mentioned above?

[k0k0pelli]

I had a closer look at the problem, and I think that the above situation is actually handled wrong by jBPM 4.4. I made a patch for head revision 6902 of the jbpm 4 repository (to whom it may concern, see attached). It disables the kill mechanism by default but provides also an attribute (called end-concurrent) for the join element to enable the kill machnism. However, there may be better solutions, e.g. to avoid this kind of kill mechanisms at all, which should be discussed.

[jnhelal]

Hi Silvio

We rely on the relased 4.4 and we have comparable problem:

• 2 branches fork/join works fine without specifying the multiplicity attribute
• 2 branches fork/join with multiplicity = 1 leave the unjoinded branch as a normal executing task while the joined execution goes on. What is wrong is that THERE EXIST 2 executions after the join.

I aggree with you, this is abnormal and I can confirm it exists on the JBPM 4.4 release, and has be reported elswhere.

I do not see why Ronald thought about a kill flag. In any case a not joined execution should be set to state END or inactive or killed. It should not remain active because this lead to uncorrect implementation of the JPDL join semantic. Maybe also this has to do with the time people thought about using this multiplicity attribute to deal the JPDL for/loop semantic...

Thanks for your patch, I will take a look at it, but I'm not the expected expert and we might need some additional help on this question.

Regards

JeanNo Helal

[k0k0pelli]

Hi Jean-Noel

I had a look on the ticket in Jira after you gave the hint. Actually, the ticket 2922 (see https://issues.jboss.org/browse/JBPM-2922) seems to solve the issue. I applied the patches from the 10th September given there. After a brief test, it seems to solve the issue, without the introduction of any additional attributes in the xml. However, it is not clear when this patch will be applied to the repository.

regards

Silvio

[k0k0pelli]

Actually, I found again a situation which is similar to the one above and which does not work with the patch given in JIRA issue 2922 (see https://issues.jboss.org/browse/JBPM-2922). I tested it with the patch I made and it worked without any problems. Thus, I suggest to use my patch (see post no. 4 above). Nevertheless, it would be still great to discuss whether my solution is appropriate or not to fix the problem.

[marcusk]

Silvio, thanks for your efforts! I have a similar issue with JBPM 4.5 (from SVN) involving a for-each nested in a fork-join. Your patch resolves this.

I did have to add end-concurrent="true" to a couple of unittests to make them work. These changes are in the attached patch.

[k0k0pelli]

Marcus, thank you for completing the patch by adding the end-concurrent flag to the test cases.