Silvio Meier [http://community.jboss.org/people/k0k0pelli] created the 
discussion

"Re: Strange behavior with JBPM 4.4 and nested fork/joins with Multiplicity"

To view the discussion, visit: http://community.jboss.org/message/594050#594050

--------------------------------------------------------------
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/showImage/2-594050-14573/Test.png
  
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
 
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:

1. 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 
2. Running exections are aborted only iff they will end inthe join to complete.
3. 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?
--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/594050#594050]

Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2034]

_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to