Fork --> Join issues

[qpool.char]

I have a small problem here:

Processdefinition contains a situation, where a fork has 3 child-taskNodes and just 2 of them will join again:

TaskNode A -------> Fork

Fork --------> TaskNode B
Fork --------> TaskNode C1
Fork --------> TaskNode C2

TaskNode B ---------> EndState

TaskNode C1 ---------> Join
TaskNode C2 ---------> Join

Join ---------> TaskNode D


Now, when executing this path after the fork, the following procedures WORK:

B .signal()
C1 .signal()
C2. signal()

or

C1.signal()
B.signal()
C2.signal()

So as long as B has ended before C1 and C2, everything seems to be ok.

But if C1 and C2 end before B, then the only open task is Task B. But Task D, which should occur after the JOIN, is missing.

I check all taskInstances of one certain processInstance with

TaskMgmtInstance taskMgmt = processInstance.getTaskMgmtInstance();
Collection<TaskInstance> allTaskInstances = taskMgmt.getTaskInstances();

Searching the forum results in some posts that say:
- a JOIN is always coupled with a FORK in some way (i guess its the nearest fork then)
- a JOIN expects exactly the number of incoming tokens that the fork created

Is this right? But this behaviour wouldn't explain why it works with ended B, but not otherwise...

Is there any workaround?

Btw @Kukeltje: I searched in the CVS for unit-tests, but could you give me a hint where to find them? I checked out "jbpm.3".

Thx in advance
alex

thx in advance

[kukeltje]

Is this right?

Yes, fork-join have to be fulle nested.... 3 from fork -> 3 to join

But this behaviour wouldn't explain why it works with ended B, but not otherwise...

The flow you describe is unsupported and thus the behaviour is undefined. Finding an explanation is (imo) therefor not a high priority.

The tests are in jbpm.3/jpdl/jar/src/test

[pojomonkey]

"QPool.Char" wrote:
Is this right? But this behaviour wouldn't explain why it works with ended B, but not otherwise...

Without delving into the code, it makes sense to me.

If B has completed, then the associated token will have ended.

Hence, when the other tokens reach the join, all the tokens are accounted for and the parent token can advance.

If B is not yet complete, then the parent will end up waiting (indefinitely) for the token as, without any further tokens ending at the join, there is no trigger to release the parent token.

"QPool.Char" wrote:
Is there any workaround?

Perhaps a custom node on one of the fork transitions can generate the task?

[kukeltje]

I would not go for such 'hacks'.... most of the time these 'issues' can be resolved by looking that the process in a different way........

[qpool.char]

Thank you both for your quick answers.

I know understand the behaviour of this situation and would agree with kukeltje. I can make a restriction here for the analyst and ask him to design processes in different ways.