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...