Event Manager configuration settings

To understand how the IBM® Business Process Manager Event Manager works, review the configuration properties.

Do not directly edit the 80EventManager.xml file; use the 100Custom.xml for any required configuration changes. For information about changing configuration properties, see Changing IBM Process Server properties in 100Custom.xml.

Task loader properties

The task loader is a dedicated thread of an Event Manager instance that loads Event Manager tasks into in-memory queues. The default parameter settings of the task loader are optimized for most usage patterns. Typically there is no need to tune any of these parameters.

<loader-long-period>15000</loader-long-period>: Specified milliseconds between major loads of the task loader. For every task loader long period, the Event Manager looks at each synchronous and asynchronous queue that it has access to and fills them to capacity.
<loader-short-period>2000</loader-short-period>: Specifies milliseconds between minor loads of the task loader. For every task loader short period, the Event Manager looks through each of the queues that the Event Manager filled to capacity during the last short or long period, and fills them to capacity. Do not change this setting.
<loader-advance-window>15000</loader-advance-window>: Specifies milliseconds before execution that the task loader can acquire a task For scheduled tasks, this parameter specifies how far in advance the Event Manager looks for tasks. Recommendation: set this property as equal to <loader-long-period>. The value is set to 15000 by default, which is the same as the <loader-long-period> value.
<kick-on-schedule>true</kick-on-schedule>: If set to true, the task loader is kicked into an immediate major load anytime a new task is scheduled. Newly scheduled tasks are executed almost immediately. Do not change this setting.

Queue capacity properties

The Event Manager queues are used for scheduling Event Manager tasks. When you define an undercover agent in Process Designer, you specify whether to use a particular synchronous queue or the asynchronous undercover agent (UCA) queue.

Tip: Throttling the Event Manager is done by decreasing the queue capacity. Note that it is not done by decreasing the thread pool with the max-thread-pool-size property, which only specifies the number of threads in the pool, not the actual number of threads that can be used by the Event Manager.

<sync-queue-capacity>10</sync-queue-capacity>: Specifies the maximum number of Event Manager tasks that are loaded into memory for each synchronous UCA queue.
<async-queue-capacity>10</async-queue-capacity>: Specifies the number of Event Manager tasks that are loaded into memory for the asynchronous UCA queue.
<bpd-queue-capacity>40</bpd-queue-capacity>: Specifies the number of Event Manager tasks that are loaded into memory for the business process definition (BPD) queue, which is an asynchronous queue that covers Event Manager tasks that execute BPDs, timers, system tasks, and decision tasks.
Tip: To optimize throughput and scaling, start with a bpd-queue-capacity of 10 per physical processor core (for example, 40 for a 4-processor core configuration), with a maximum value of 80.
<system-queue-capacity>10</system-queue-capacity>: Specifies the number of Event Manager tasks that are loaded into memory for the Event Manager internal system queue, for example, blackout calendar update tasks.

Thread pool properties

The thread pool properties designate the worker threads that are used by Event Manager.

<use-was-work-manager>true</use-was-work-manager>: Specifies whether the WebSphere Application Server Work Manager is designated for the thread pool. It is set to true by default. Changing this value to false is not recommended, because setting the value to false would, for example, disable visibility in IBM WebSphere Application Server resource monitoring tools. The Work Manager is configured on the administrative console at the cluster level.
Note: The total available IBM Business Process Manager database connections in the application server connection pool should be at least twice the number of the maximum Event Manager worker threads. The number of connections on the actual database server needs to be at least the sum of the maximum thread number for all nodes in the cluster. If <use-was-work-manager> is true, the number of threads is configured in the work manager thread pool configuration. If <use-was-work-manager> is false, the maximum number of threads is the sum of the BPD queue capacity plus the asynchronous queue capacity plus the system queue capacity plus number of synchronous queues.
The web container threads also need database connections.
<was-work-manager>wm/BPMEventManagerWorkManager</was-work-manager>: Specifies the WebSphere Application Server Work Manager that is used.
Tip: Throttling the Event Manager is done by decreasing the queue capacity. If you are using <was-work-manager> thread pool, it limits the concurrency of Event Manager threads. It should be large enough to support the queue’s capacity. Set this parameter to the size of bpd-queue-capacity plus async-queue-capacity plus system-queue-capacity plus number of sync-queues.
<min-thread-pool-size>5</min-thread-pool-size>: Specifies minimum number of threads for the Event Manager engine thread pool, if the WebSphere Application Server Work Manager is not used.
<max-thread-pool-size>50</max-thread-pool-size>: Specifies maximum number of threads for the Event Manager engine thread pool, if the WebSphere Application Server Work Manager is not used.
Tip: To optimize throughput and scaling, start with a max-thread-pool-size size of 30 plus 10 per physical processor core (for example, 70 for a 4-processor core configuration), with a maximum value of 110.
<re-execute-limit>5</re-execute-limit>: Specifies maximum number of times the Event Manager will try to execute a task if it ends with an exception.
Tip: Event Manager tasks that fail and reach the re-execute-limit are put on hold. The tasks are retained in the database, but they are flagged to be on hold and rescheduled to be run in the future when the BPMReplayOnHoldEMTasks command is run.

Heartbeat properties

A heartbeat is a dedicated thread of an Event Manager instance that periodically signals that the Event Manager instance is still running.

<heartbeat-period>30000</heartbeat-period>: Specifies milliseconds between heartbeats. Do not change this setting. If the setting is changed, it must be less than the <heartbeat-expiration> divided by 4.
<heartbeat-expiration>240000</heartbeat-expiration>: Specifies milliseconds for a heartbeat to expire. Do not change this setting. If the setting is changed, it must be larger than 4 times the <heartbeat-period>.

Reaper property

A reaper is a dedicated thread for each cluster member that checks if there are Event Manager tasks owned by expired Event Manager instances. If it finds those tasks, the reaper resets the state to scheduled and the ownership to unassigned. Therefore, other Event Manager instances pick up the work.

<reaper-period>120000</reaper-period>: Specifies milliseconds between activity of expired Event Manager reaper. Do not change this setting.

Other Event Manager properties

<start-paused>false</start-paused>: Allows the Event Manager to be started in paused state. The Event Manager can be resumed using the Event Manager monitor in the Process Admin Console.
<name>EM instance name</name>: Specifies name of the Event Manager instance. The name is used in Event Manager monitor in the Process Admin Console.