JBoss Community

Gregory, stale state exceptions are to be expected if your process definition contains concurrent paths. Managing these exceptions has been the subject of multiple issues. In JBPM-1952 the JMS message service was reviewed and the queue configuration was changed as follows.

JBossMQ (AS 4.x)

<mbean code="org.jboss.mq.server.jmx.Queue"
  name="jboss.mq.destination:service=Queue,name=JbpmJobQueue">
  <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
  <!-- JBPM-1952 a small redelivery delay goes a long way towards mitigating
       stale state exceptions and deadlocks under heavy concurrency conditions -->
  <attribute name="RedeliveryDelay">1000</attribute>
</mbean>

JBoss Messaging (AS 5.x)

<mbean code="org.jboss.jms.server.destination.QueueService"
  name="jboss.messaging.destination:service=Queue,name=JbpmJobQueue"
  xmbean-dd="xmdesc/Queue-xmbean.xml">
  <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
  <depends>jboss.messaging:service=PostOffice</depends>
  <!-- JBPM-1952 a small redelivery delay goes a long way towards mitigating
       stale state exceptions and deadlocks under heavy concurrency conditions -->
  <attribute name="RedeliveryDelay">1000</attribute>
</mbean>

In JBPM-2790 the job executor and the join node were improved as follows.

• End concurrent token when it enters the join node. Check all children of the parent token have ended when the join executes.
• Make a small pause in the job executor thread before retrying a failed  job. Retrying a failed job too soon will likely produce another SOSE or  deadlock.

For best results, the join node should be made asynchronous in order to reduce the window of opportunity for a locking conflict.