8 Replies Latest reply on Sep 10, 2010 8:00 AM by swiderski.maciej

Joining of non-concurrent decision paths seems to be broken in 4.4

h.peter Jul 30, 2010 5:17 AM

Hello All,

We have a quite complicated process definion with a lot of cases where a step has to be executed only on a specific condition - something like the following diagram (see attached full example process definition JPDL file):

We used join nodes with multiplicity="1" setting to join the two possible outcome paths of the decision node:

This approach used to work OK with JBPM 4.3 but it fails with version 4.4.

I believe that the handling of join nodes has been changed in this version: the second join node (the last one before the end in the example) seems to get the incoming executions with an invalid, "ended" state, so it fails with the following exception:

Exception in thread "main" org.jbpm.api.JbpmException: execution[ForkJoinTest.10001.to script2.10002] is not active: ended
    at org.jbpm.pvm.internal.model.ExecutionImpl.checkActive(ExecutionImpl.java:1084)
    at org.jbpm.pvm.internal.model.ExecutionImpl.take(ExecutionImpl.java:481)
    at org.jbpm.jpdl.internal.activity.ForkActivity.execute(ForkActivity.java:95)
    at org.jbpm.jpdl.internal.activity.ForkActivity.execute(ForkActivity.java:46)
    at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:60)
    at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:672)
    at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:632)
    at org.jbpm.pvm.internal.model.ExecutionImpl.start(ExecutionImpl.java:217)
    at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:63)
    at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:36)
    at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
    at org.jbpm.pvm.internal.tx.SpringCommandCallback.doInTransaction(SpringCommandCallback.java:45)
    at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)
    at org.jbpm.pvm.internal.tx.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:49)
    at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
    at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
    at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:56)
    at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.startProcessInstanceByKey(ExecutionServiceImpl.java:67)

For me, this seems to be a bug - clearly, the behaviour of JBPM has been changed between version 4.3 and 4.4. The attached process definition is executed correctly with JBPM 4.3.

What do you think about this?

Regards,

Peter

ForkJoinTest.jpdl.xml 1.3 KB

1. Re: Joining of non-concurrent decision paths seems to be broken in 4.4

rebody Aug 1, 2010 9:39 PM (in response to h.peter)

Hi Peter,

In jBPM4.4, when we used mutiplicity attribute, then join will try to delete every branch executions. This could prevent the next step of join being executed multiple times.

But seems it couldn't handle embbed forks correctly. Could you open an issue for that? We could handle it later, Thank you very much.
1 of 1 people found this helpful
Actions
2. Re: Joining of non-concurrent decision paths seems to be broken in 4.4

h.peter Aug 3, 2010 11:17 AM (in response to rebody)

Hello HuiSheng,

I've created a JIRA for this: https://jira.jboss.org/browse/JBPM-2922

Regards,
Peter
Actions
3. Re: Joining of non-concurrent decision paths seems to be broken in 4.4

swiderski.maciej Aug 9, 2010 3:24 PM (in response to h.peter)

Hi guys,

the issue is not related to nested forks, in fact it is caused by too many joins compared to fork. As you can see first join that is used to merge executions that where split by decision activity is not aware that there will be any other join later on. When execution arrives to it, join is completed based on the multiplicity attribute and ends any other not joined paths.

You could change your process definition to remove join1 and point all to join2 and set multiplicity attribute on it to 2, that would probably work just fine.

I agree that a good practice would be to use gateways to join exclusive paths but it looks to me (correct me if I am wrong) that somehow we are mixing two types of gateways here - exclusive at the beginning and then parallel.

This feature was introduced to make sure we are not going to leave any orphans when join is completed.

Let me know what do you think about it.

Cheers
1 of 1 people found this helpful
Actions
4. Re: Joining of non-concurrent decision paths seems to be broken in 4.4

h.peter Aug 12, 2010 4:19 AM (in response to swiderski.maciej)

Hello Maciej,

Our process definition is quite large and complicated, and we added extra join nodes to prevent the diagram from becoming spaghetti-like. According to the documentation, the join node simply waits the the number of executions specified in the multiplicity attribute (or the number of incoming transitions if multiplicity is not specified) that should arrive before the it gets activated and takes the outgoing transition. This is exactly what happens in JBPM 4.3.

I understand that this change was introduced to address some edge-cases but I think - from the user's point of view - it is a regression in functionality as such usage of join nodes was valid in the previous version.

My feeling is that the assumption, that the process contains the same number of join and fork nodes on every possible execution paths, is not correct and may cause further problems. A lot of people with a bit more complicated process definition migh find that it breaks after the migration to the latest version of JBPM.

Regards,
Peter
Actions
5. Re: Joining of non-concurrent decision paths seems to be broken in 4.4

swiderski.maciej Aug 13, 2010 9:14 AM (in response to h.peter)

Hi Peter,

completely agree with you. What I could suggest is to introduce additional attribute to join node that will enable/disable of ending remaining executions.
Firstly - do you agree?
In my opinion as important as having join working properly as merge point after decision is to close down forked executions that did not reach merge point before execution moved on.
By introducing additional attribute could most likely sort out these issues but question is about behavior:
- shall ending execution be enabled by default or the other way around
- shall the attribute refer to ending executions or to types of paths being merged (decision path, forked paths)
Actions
6. Re: Joining of non-concurrent decision paths seems to be broken in 4.4

h.peter Sep 9, 2010 1:11 PM (in response to swiderski.maciej)

Hi Maciej,

Sorry for the delay, I've been really busy.

This is an interesting idea and I believe that internally it could work like that. But assuming there is a way you can always deciede wheter to set this flag or not, I think the engine should be responsible for doing that - having to "hint" it if the concurrent executions have to be ended or not does not seem to be the way it should work.

Basically the question is that if there is any algorithm you can use to figure out whether the concurrent executions should be ended or not. I believe the answer is yes: my understanding is that this error happens if you have more join nodes than fork nodes on the path of the current execution. In that case jBPM could simply traverse the graph of the execution to check the number of fork and join nodes hit so far and set this flag accordingly which then could drive the decision whether the concurrent executions are to be ended or not.

Let me know what you think about this approach
Actions
7. Re: Joining of non-concurrent decision paths seems to be broken in 4.4

swiderski.maciej Sep 10, 2010 2:15 AM (in response to h.peter)

Hi Peter,

in fact that would not be a problem if jBPM has two types of nodes that converge executions (exclusive and parallel). To be honest I was thinking as well to introduce new type of join node but it would be only to have capability of informing the engine if it is exclusive or parallel - exactly the same what this new attribute does.

I agree that deciding about what kind of join it is is responsibility of the engine. I will take a look at possibilities of implementing what you described and post back the result.

Thanks a lot for very good ideas and engagement in this.
Actions
8. Re: Joining of non-concurrent decision paths seems to be broken in 4.4

swiderski.maciej Sep 10, 2010 8:00 AM (in response to swiderski.maciej)

ok, seems like it is possible. I attached new patch to jira that should take care of this issue. Review and comments are appreciated.
Actions

Go to original post