BPM queue consumer thread pool (Product 360)

Threads of this thread pool are consuming the message queue and in memory queue and does dispatch request from Product 360 to the BPM workflow engine.

The thread pool size can be configured in the server.properties file with following entry:

BPM request rate limit (Product 360)

Since version 8.1.1.04 and 8.1.0.05 there is the possibility to force a maxium rate of requests per second from Product 360 against the BPM engine.

The configuration for that limitation is within the server.properties:

To determine the current rate there is a log4j.xml setting which can be enabled. If the setting is enabled, the Product 360 server logs every second how many requests are being sent in that interval. If there is nothing sent there will be no log message.

Dispatcher service (BPM)

The dispatcher service is optional, but if configured allows to enable a buffering queue for the incoming request into the BPM engine.

The dispatcher service allows to specify how many threads in parallel are invoking active processes.

To create a dispatcher service configuration you have to add a configuration via Monitor → Process Monitoring → Dispatch Service

When adding a new configuration it is possible to adjust following settings:

The important setting is the "Max Concurrent" entry.

As a rule of thumb it can be said, that a single thread of the dispatch service can handle about 10-40 requests per second.

Virtual process instance thread pool (BPM)

The BPM engine allows to limit the number of simultaneously running process instances.

To configure the relevant settings go to Admin → Configure Server → Server Properties

There it is possible to configure the "Process Count" setting.

Work manager thread pool (BPM)

The BPM engine has a worker thread pool where the process instances and all subprocess instances are running upon.

To configure the relevant settings go to Admin → Configure Server → Server Properties

There it is possible to configure the "Work manager thread pool max" setting.

BPM queue consumer thread pool (Product 360)

If no explicit setting is configured, the thread pool is initialized with a size same to the number of processor cores.

If the thread pool has to be configured, it is normally not necessary to configure it to a high number, as each thread can consume and dispatch up to hundreds of messages per second as long as the BPM workflow engine is not blocking or delaying the REST requests.

BPM request rate limit (Product 360)

If the BPM server is putting the Product 360 system or the database too much under load, it is possible to configure the request rate limit.

The rate can be even configured to less requests per second than even a single thread is producing (10-40).

To use this rate limiting step is only blocking the message queue consumer thread pool and no other thread pool, that is why this is considered to be the best option, if the rate should be limited.

Work manager thread pool (BPM)

The worker thread pool size should be configured to be larger than the "Process Count" * (1+ number of subprocesses per workflow).

The reason for this is, that assumed there is a process count defined which is 50 and also a worker thread pool max size configured of only 50. If 50 incoming requests will instantiate 50 threads with the main processes of a workflow, not a single instance is able to spawn subprocesses anymore. If subprocesses are mandatory for the main processes, they all end up in a dead lock state. So it is important to have enough space in the worker thread pool to ensure that spawning of subprocesses is possible at any time.