Workflow Engine

AVEVA Work Tasks services can have their own monitoring logic. The monitoring logic is executed by the Client Service.

Monitoring the thread pool and checking the engine hanging behavior:

At times, the Workflow Engine is unable to execute the Workflows though sufficient memory is available. In addition, it may not even throw up a MemoryOutOfException. The reason could be that some workflow threads may be hanging and may not be released from the thread queue. Eventually, the pending workflows do not get the thread queue and hence do not get processed.

The Workflow Engine has a default thread pool configuration of 30 threads. However, repositories can have their own configuration in the Farm's SKConcurrentThreadPools.

For more information, see Thread Pools at Repository Level in the Build Business Process section.

For example, if there are three repositories where "Repository A" has a thread configuration of 20 threads in SKConcurrentThreadPools and "Repository B" and " Repository C" have no configurations in SKConcurrentThreadPools.

Then the total configured threads will be 20 + 30 = 50 threads.

The Client service will check the InternalStatus and LastUpdatedDateTime columns of the SWExecute table. After a new workflow execution starts, its status will be “ex” (executing) and LastUpdatedDateTime will be the current datetime. If a workflow status is "ex" for a duration of about 10 minutes (Configuration Settings in WFEngineThreadScanInterval node), then the engine is hanging as the workflow is not yet processed completely.

Out of 50 threads, if 30 threads are hanging, that is if their status is not changed from executing to complete, then there are chances that a lot of workflows are pending in queue. Hence, the Workflow Engine is hanging. The Client service has a threshold value of about 70% (Configuration Settings in the WFEngineThreadThresholdValue node). After the number of hanging threads reaches the threshold value, the service is restarted and hence all the threads are freed.

After the Client service is started followed by a change in the value of SKConcurrentThreadPools, then the Client service needs to be restarted to monitor with the updated values. Values from SKConcurrentThreadPools are cached in the Client service. This cache can be broken and recreated after the Client service is restarted.