David Edery [https://community.jboss.org/people/d_edery] created the discussion

"Old JBPM (ver 3.2.7) non-logical exception "org.jbpm.JbpmException: transition 
'no-work-done' does not exist on Node(preScan)""

To view the discussion, visit: https://community.jboss.org/message/717230#717230

--------------------------------------------------------------
Hi
We are using JBPM 3.2.7 in our large-scale application for a long time now.
Recently, due to race-conditions with the DB commit we have decided to move 
from persistent mode (in which all the process-definitions, process-instances 
etc... were stored in the DB) to non-persistent that works in the following 
flow:
1. We read all the .xml files containing process definitions.
2. For each .xml file we create a process definition and store it in a static 
map.
3. When the user wants to activate a flow (it's usually the same flow on 
multiple targets) - *we create a new ProcessInstance based on the same instance 
of ProcessDefinition* (this might explain the phenomena but we didn't see how 
from the code).
4. Each thread in a dedicated thread pool takes one ProcessInstance and 
activates it (via .signal).
5. Each action calls the .signal (with or without transition name) in the end 
of its business logic - thus creating a synchronized workflow.

Recently we have encountered a problem (it occurred only one time) that caused 
failure in some of the targets (ProcessInstances).
The exception was (full stack-trace attached to the discussion, highlighted 
lines describe the flow):

*org.jbpm.JbpmException: transition 'no-work-done' does not exist on 
Node(preScan)*
    at org.jbpm.graph.exe.*Token.signal*(Token.java:170)
    at 
com.yyyy.nms.massconfig.swdownload.*PreScanAction.run*(PreScanAction.java:42)
    at com.yyyy.nms.massconfig.common.*BaseAction.execute*(BaseAction.java:71)
    at org.jbpm.graph.def.Action.execute(Action.java:137)
    at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:280)
    at org.jbpm.graph.def.Node.execute(Node.java:395)
    at org.jbpm.graph.def.Node.enter(Node.java:375)
    at org.jbpm.graph.def.Transition.take(Transition.java:151)
    at org.jbpm.graph.def.Node.leave(Node.java:453)
    at org.jbpm.graph.exe.Token.signal(Token.java:214)
    at org.jbpm.graph.exe.*Token.signal*(Token.java:143)
    at 
com.yyyy.nms.massconfig.common.*FirstWorkflowAction.run*(FirstWorkflowAction.java:94)
    at com.yyyy.nms.massconfig.common.*BaseAction.execute*(BaseAction.java:71)
    at org.jbpm.graph.def.Action.execute(Action.java:137)
    at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:280)
    at org.jbpm.graph.def.Node.execute(Node.java:395)
    at org.jbpm.graph.def.Node.enter(Node.java:375)
    at org.jbpm.graph.def.Transition.take(Transition.java:151)
    at org.jbpm.graph.def.Node.leave(Node.java:453)
    at org.jbpm.graph.node.StartState.leave(StartState.java:78)
    at org.jbpm.graph.exe.Token.signal(Token.java:214)
    at org.jbpm.graph.exe.*Token.signal*(Token.java:143)
    at org.jbpm.graph.exe*.ProcessInstance.signal*(ProcessInstance.java:287)
    at 
com.yyyy.nms.jbpmworkflow.*JbpmWorkflowInvoker*.startNonPersistentWorkflow(JbpmWorkflowInvoker.java:271)
    at 
com.yyyy.nms.jbpmworkflow.*JbpmWorkflowInvoker*.startWorkflow(JbpmWorkflowInvoker.java:350)
    at 
com.yyyy.nms.jbpmworkflow.StartWorkflowMDB.signalWorkflow(StartWorkflowMDB.java:101)
    at 
com.yyyy.nms.jbpmworkflow.*StartWorkflowMDB*.handleMessage(StartWorkflowMDB.java:85)

In the .xml file from which the related ProcessDefinition was read looks like 
this (in the relevant part):

<exception-handler>
     <action class="com.yyyy.nms.massconfig.common.ExceptionAction" />
</exception-handler>

<start-state>
     <transition to="check-suspend-or-abort"></transition>
</start-state>

<node name="check-suspend-or-abort">
     <action class="com.yyyy.nms.massconfig.common.FirstWorkflowAction" />
     <transition to="preScan"/>

     <transition to="error" name="error"/>
     <transition to="suspended" name="suspended"/>
     <transition to="aborted" name="aborted"/>
</node>


<node name="preScan" description="Pre-upgrade Scan" shouldField="preScan">
      <action class="com.yyyy.nms.massconfig.swdownload.PreScanAction" />

     <event type="node-enter">
          <action class="com.yyyy.nms.massconfig.common.StepStartAction" /> 
     </event>

     <transition to="acquireFtpForUpload"> 
          <action class="com.yyyy.nms.massconfig.common.StepDoneAction" />
     </transition>

     <transition to="acquireFtpForUpload" name="no-work-done"> 
          <action class="com.yyyy.nms.massconfig.common.StepSkippedAction" /> 
     </transition>

     <transition to="error" name="error"/>
     <transition to="suspended" name="suspended"/>
     <transition to="aborted" name="aborted"/>
</node>


As you can see, if we are in the "preScan" node - we definitely have the 
"no-work-done" transition.

The scenario that produced this exception contained 40 process instances (=40 
different targets) based on the same ProcessDefinition instance. Out of which 7 
targets failed on this exception and the rest (which went through the same 
nodes and transitions) completed successfully (before and after the 7 failed).

The only clue to a possible problem was that the JBPM exception thrown for all 
7 targets was thrown *at the same exact time* (same millisecond even). Meaning 
- all 7 tried to perform the .signal("no-work-done") in the PreScanAction at 
the same exact time.
We have generated the same scenario on our development environment (using 
CountDownLatch in the prior to the .signal("no-work-done")) with 10 targets 
that wait together and all of them call the .signal("no-work-done") in the same 
exact millisecond - the failure was not reproduced.

Our question is - did you encounter such scenario? If so - was it fixed in 
newer versions? can we bypass it? (I thought about creating a new 
ProcessDefinition per ProcessInstance - this will cost a lot in terms of memory 
consumption and CPU load - but since I couldn't reproduce the problem, I'm not 
sure that it will solve it).

Oh, we create the ProcessDefinitions map during server load. We don't change 
them after the creation of the map.
As you can see in the attached screenshot (from LogMX) - this is how it looks 
like, 7 different threads throw the same exception on the same time.
 
https://community.jboss.org/servlet/JiveServlet/showImage/2-717230-17993/transitionProblem.GIF
  
https://community.jboss.org/servlet/JiveServlet/downloadImage/2-717230-17993/450-133/transitionProblem.GIF
 
Thank you for your time.
Sincerely
David Edery.
--------------------------------------------------------------

Reply to this message by going to Community
[https://community.jboss.org/message/717230#717230]

Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2034]

_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to