Hi Gregory,

I don't know of any delays you can configure on JBoss AS to stall the relaying of JMS messages, but you might not want to change something like that at such a level - that may impact other applications running in the same environment, and you never know which those may be over time.

There is a way to delay the execution of Jobs, however, and it's quite simple, albeit a little labourious if you need it often.

You would need to call the setDueDate(Date dueDate) method on all of the Job objects you're scheduling. Just using new Date() as the input value schedules them for right now, adding the amount of time you need for a delay should do the trick. (And for that, DateUtils in Apache's commons lang library may be helping out, or you could use jBPM's own BusinessCalendar too).

HTH!

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.