Alarms do not Expire

Sometimes, when the a BPEL process have a lot of Wait and onAlarm activities (or there are many BPEL instances running that use Wait or onAlarm) then some of the Alarms may not fire.

The BPEL engine makes use of Quartz in numerous ways, mainly for expiration of wait and onAlarm activities, but also for:

  • sending periodically "pings" to the dispatcher to flush out stranded messages
  • enabling polling for custom activation agents
  • scheduling execution of activities that need to be performed in the future (for example, mail receive activities).

In 10.1.x releases of BPEL, the number of Quartz threads can be tuned by changing the*.threadCount properties in ORACLE_HOME/bpel/domain/DOMAIN_NAME/config/ file.

BPEL uses Quartz to schedule expiration events for Wait and onAlarm activities, and the parameter that controls number of threads for this is

There is no specific formula for calculating it, as this is a parameter that would require some tuning to set it to the best value suitable for your environment. The default value is 10, and for start you can try to set it to 30 and test. If still the number is too low, you can try to further increase to 50 or a higher value. Be careful that setting it too high, will result in increased overhead, because too many threads are created.

Sample setting of expirationAgent in

# - schedules wait/onAlarm activities;
# this is the most heavily used agent in the system. If your flows
# typically have many wait/onAlarm activities and the total number of
# instances created is high, performance may suffer if the expiration agent
# thread count is not sufficient to handle the load. In worst-case not
# having enough threads to handle high incoming request counts may result
# in OutOfMemory errors as the number of scheduled tasks piles up.
# = 30

Posted in Labels: , , |


  1. Anonymous Says:

    Thanks for posting this. It helped us a lot.