As nobody answers, I'd like to illustrate the problem again with a simplerexample as given above. The following example shows the above problem in asimplified way:
http://community.jboss.org/servlet/JiveServlet/downloadImage/2-594050-14573/450-366/Test.png
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, whichare alternatives that are chosen by a decision (exclusive1). Task 4 executes inparallel to task2 or task3, depending on the alternative that is chosen. Becausethere are three transitions ending in the inner join activity (join2), amultiplicity must be specified, as otherwise the join does not go on with itsexecution.
However, with the current implementation of jBPM 4.4, depending on the waythe workflow is executed, a strange behavior can be created.
Executing first task1, causes anormal execution, i.e., all tasks are executed as expected. However, finishingfirst the inner join activity (join2) leads to a strange behavior, which is dueto 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 didnot arrive in any join, if there is amultiplicity given in the join activity, which is probably the source of the problem. It should just kill thenon-finished executions that end in the join activity to complete and not *all*(concurrent) executions.
If task2 or task3, respectively, and task4 are finished before task1, the procedure completing the inner joinactivity (join2) deletes also the active exection of task1, even though thisshould not be the case.
From my point of view, there are three possible solutions:
- We introduce a flag for switching the kill mechanismoff, as this was suggested in the above mentioned Jira ticket. However, I didnot find anything like that in the implementation. This is maybe the simplersolution as the one suggested in
- Running exections are aborted only iff they will end inthe join to complete.
- Remodeling the workflow using no nested join/forks. However, this solutions is not possible in every case.
Did someone encounter the same problems and is there a simpler solution thanthe three soluteonsd above?
