[
https://jira.jboss.org/jira/browse/JBPM-1906?page=com.atlassian.jira.plug...
]
Mauro Molinari commented on JBPM-1906:
--------------------------------------
In any case, I think there's a problem here.
First of all, if the join is supposed to collect all the children of a parent token that
where created by a fork, I would expect that jBPM didn't allow me to create a process
definition like the one I attached.
Secondly, even if the process definition is accepted, I don't see any good reason for
jBPM to behave differently if I first signal the task and then the wait state or
viceversa.
In particular, the user guide says:
"The default join assumes that all tokens that arrive in the join are children of the
same parent. This situation is created when using the fork as mentioned above and when all
tokens created by a fork arrive in the same join. A join will end every token that enters
the join. Then the join will examine the parent-child relation of the token that enters
the join. When all sibling tokens have arrived in the join, the parent token will be
propagated over the (unique!) leaving transition. When there are still sibling tokens
active, the join will behave as a wait state."
Strictly speaking, if you interpret "when all sibling tokens have arrived in the
join, the parent token will be propagated" as that ALL of the children of the parent
token MUST arrive in the join, so case A should fail. Instead, if you interpret the same
sentence like "all the sibling token [that could arrive] have arrived in the
join", then case B should succeed.
Anyway, the process definition I attached is obviously a pathological case, but I think
there can be some reasonable cases where not all tokens generated by a fork may arrive in
the corresponding join. A task node or a decision node on one of children path might make
the flow propagate to an end state rather than to the join, depending on the user action
or on the process instance state and I would expect the process flow to continue if there
are other paths that have not terminated because of an end state or a cancellation...
The fact that tokens that arrive in a join are "ended" I think should remain an
"implementation detail" or, at least, I wouldn't consider equally a
termination caused by an end state to that caused by a child token that arrives in a
join.
Mauro.
Inconsistent behaviour depending on the ordering of events (fork+end
state+join)
--------------------------------------------------------------------------------
Key: JBPM-1906
URL:
https://jira.jboss.org/jira/browse/JBPM-1906
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Core Engine
Affects Versions: jBPM 3.2.3
Reporter: Mauro Molinari
Priority: Critical
Fix For: jBPM 3.3.2 GA
Attachments: Test bug JBPM-1906.zip
Given the following process definition:
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2"
name="Complex">
<description>
Complex description
</description>
<start-state name="start-state1">
<transition to="task-node1"></transition>
</start-state>
<task-node name="task-node3">
<task name="Task3_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="end-state1"></transition>
</task-node>
<node name="node1">
<transition to="task-node3"></transition>
</node>
<join name="join1">
<transition to="node1"></transition>
</join>
<fork name="fork1">
<transition to="task-node2"></transition>
<transition to="node2" name="to node2"></transition>
<transition to="state1" name="to state1"></transition>
</fork>
<task-node name="task-node2">
<task name="Task2_1">
<assignment actor-id="1"></assignment>
</task>
<task name="Task2_2">
<assignment actor-id="1"></assignment>
</task>
<transition to="join1"></transition>
</task-node>
<task-node name="task-node1">
<task name="Task1_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="fork1"></transition>
</task-node>
<node name="node2">
<transition to="end-state2"></transition>
</node>
<state name="state1">
<transition to="end-state2"></transition>
</state>
<end-state name="end-state1"></end-state>
<end-state name="end-state2"></end-state>
</process-definition>
Try to do this:
- create a process instance and start it
- a Task1_1 instance is created: end it
- the root token halts at the fork and three children tokens are created
1) the first causes the creation of a Task2_1 instance and of a Task2_2 instance
2) the second halts at the state1 state
3) the third dies at the end-state2 state
Now, there are two cases:
CASE A)
- signal the second token: it then goes on and dies at end-state2 state
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- now, the root token is restored and goes through node1 and task-node3 nodes, causing
the creation of a Task3_1 instance
This is what I would expect!
CASE B)
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- signal the second token: it then goes on and dies at end-state2 state
- now, the root token is ended, halting the process instance!
This is not the expected behaviour, as I would expect that the root token is restored
because now all the sibling tokens of those that have reached the join node are ended, so
the parent token (= the root token) should be restored and should continue to node1 and
subsequent nodes.
Moreover, I would not expect that the behaviour is different depending on the ordering of
the actions "signal the state1 token" and "signal the task-node2
token".
My suspect is this: in case B) the join node is not "triggered" anymore after
Task2_1 and Task2_2 are ended, so it can't restore the parent node. Moreover, when the
second children token is signalled, it reaches end-state2: jBPM then realizes that all of
the sibling tokens are also ended, so it wrongly decides that the parent token should also
be ended.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira