7 a.m.
I'm having a problem with a workflow, containing a nested fork, getting
"stuck". This only happens when tasks are completed in a certain order.
I'm wondering if someone can have a look at this as we have several customers blocked
on this one - and I have reached a dead end with trying to find a fix.
Here is the process definition:
<?xml version="1.0" encoding="UTF-8"?>
|
| <process-definition xmlns="urn:jbpm.org:jpdl-3.1"
name="wf:fundingrequest">
|
| <swimlane name="initiator" />
|
| <start-state name="start">
| <task name="wf:startFundingRequestTask"
swimlane="initiator" />
| <transition name="startToStep1" to="step1" />
| </start-state>
|
| <task-node name="step1">
| <task name="wf:step1FundingRequestTask"
swimlane="initiator" />
| <transition name="step1ToFork1" to="fork1" />
| </task-node>
|
| <fork name="fork1">
| <transition name="fork1ToDec1" to="dec1" />
| <transition name="fork1ToStep2c" to="step2c" />
| </fork>
|
| <decision name="dec1">
| <transition name="No" to="join2"></transition>
| <transition name="Yes" to="fork1a">
| <condition>#{2 > 1}</condition>
| </transition>
| </decision>
|
| <fork name="fork1a">
| <transition name="fork1aToStep2a" to="step2a" />
| <transition name="fork1aToStep2b" to="step2b" />
| </fork>
|
| <task-node name="step2a">
| <task name="wf:step2aFundingRequestTask"
swimlane="initiator" />
| <transition name="step2aToJoin1" to="join1" />
| </task-node>
|
| <task-node name="step2b">
| <task name="wf:step2bFundingRequestTask"
swimlane="initiator" />
| <transition name="step2bToJoin1" to="join1" />
| </task-node>
|
| <task-node name="step2c">
| <task name="wf:step2cFundingRequestTask"
swimlane="initiator" />
| <transition name="step2cToJoin2" to="join2" />
| </task-node>
|
| <join name="join1">
| <transition name="join1ToJoin2" to="join2" />
| </join>
|
| <join name="join2">
| <transition name="join2ToStep3" to="step3" />
| </join>
|
| <task-node name="step3">
| <task name="wf:step3FundingRequestTask"
swimlane="initiator" />
| <transition name="step3ToEnd" to="end" />
| </task-node>
|
| <end-state name="end" />
|
| </process-definition>
|
We have a custom Join class which extends the default jBPM Join class. We have this custom
Join class, because we have an Event.EVENTTYPE_NODE_LEAVE action handler
JoinEndForkedTokens class which needs to get called when the Join node is
"left".
The key thing is that the getting stuck problem only occurs when we have this custom Join
class "wired in" and the tasks are completed in a certain order
The task completion order that exibits the "getting stuck" problem is as
follows:
When task "step2c" is completed after tasks "step2a" and
"step2b", then the workflow path does not leave node "join2" - and
thus task "step3" does not get reached.
The following files are attached:
- The process definition for this nested fork workflow,
http://rapidshare.com/files/121903643/nestedfork-workflow-processdefiniti...
- The hibernate config and jbpm config files we are using
http://rapidshare.com/files/121903641/hibernate-context.xml.html
http://rapidshare.com/files/121903642/jbpm.cfg.xml.html
- A ZIP file containing our own workflow processing classes. Our custom Join class and
JoinEndForkedTokens action handler are in the jBPM folder therein.
http://rapidshare.com/files/121903644/workflow.zip.html
- Two debug log files (with debug turned on for org.jbpm and org.alfresco.repo.workflow -
the package for our workflow processing classes)
-- alfresco.step3-not-reached.log - for the above getting stuck scenario
http://rapidshare.com/files/121903639/alfresco.step3-not-reached.log.html
-- alfresco.step3-reached.log - for when "step2c" is NOT completed after
"step2a" and "step2b", and "join2" is left and
"step3" reached - and all is fine.
http://rapidshare.com/files/121903640/alfresco.step3-reached.log.html
I can't find anything wrong with our custom Join and neither our action handler
JoinEndForkedTokens class (added as an action by the custom Join code), but when I change
the hibernate and jbpm config files to point back to the default jBPM Join class, then the
workflow does not get stuck.
What I have found so far is that when the workflow gets "stuck" it is because
jBPM has "forgotten" to call the Join.execute() method (on Join2) after step2c
has been completed - the problem only happening in the scenario when step2c is completed
after step2a & step2b. But Join.execute() on Join2 is indeed called when both step2a
and step2b have been completed, and Join1 is left.
... and for some reason, this weirdness only happens when we wire in our own custom Join
class (which extends the default jBPM one).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157651#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...