Skip to main content

Symptoms

 


Suppose you observe delays with execution of one particular activity in parent process. Activity contains single IPC event (synchronous run), and contains no other events. Processing of this activity sometimes takes up to 3 minutes. It is unclear why there could be such delays with processing of IPC events and hot to get rid of them.
 

 

 

Diagnoses

 

 


Such delays can be caused by different factors ranging from K2 thread pool configuration settings and design of process itself, plus there are also some specific considerations for clustered K2 environments. For example following should be checked:

1. Check settings in K2server.setup file (in particular IPCThreadPooling)
2. Confirm that time zone settings on K2 and SQL servers match
3. Confirm that here is no other IPC events on the servers
4. Check data fields of child process to verify if there are some with large payload
5. Preceding/succeeding rules for Activity with IPC event are not set.

In certain scenarios adding a delay into child process Start Rule can help to get rid of IPC events processing delays. This is because once Start Rule is added, even one-second delay Start Rule, it moves the execution of the process Instance from the IPC thread pool to the Async thread pool.

Any thread pool (Worker, IPC, Async) that picks up an item to process, will continue to process the item up to the next asynchronous point (e.g. client event).
If there are no IPCs or Start Rules, the Worker thread pool will execute a process from start to finish. If there is an IPC, Worker thread pool will execute the process up to the IPC Event, and then IPC thread pool will take over, start the child process, execute the child process, complete it (if there are no async points in it) and continue the parent process up to the next async point in the parent process after which the Worker thread pool will take over again.
If there is a Start Rule in the process, the worker thread pool will run the process up to the start rule, next an Async record will be created for the start rule. At that point, Async threadpool will run the process up to the next async point after which the worker thread pool will take over and complete the process.
So, in this particular case, before the adding start rule:
Worker thread pool runs the parent instance up to the IPC Event and creates the IPC table records.
Next, IPC thread pool will start the child process and complete the child process if there are no async points in the child process.
And IPC thread pool continues parent process up to the next async point in parent process.
This leaves a lot of work to do for 5 IPC threads (default value is 5).

After adding start rule:
Worker thread pool runs the parent instance up to the IPC Event and creates the IPC table records.
Next, IPC thread pool will start the child process and run up to Start Rule to create the Async record.
Next, Async thread pool takes over and completes the child process if there are no async points in the child process.
Async thread pool creates IPC table records for the child to return to the parent.
IPC thread pool continues the parent process up to the next async point in the parent process.

In essence, with this start rule workaround, depending on the complexity of the child process it is possible to more than halve the IPC thread pool’s amount of work.
 

 

 

Resolution

Consider adding delay into child process StartRule. In certain scenarios adding a delay into child process Start Rule can help to get rid of IPC events processing delays. This is because once Start Rule is added, even one-second delay Start Rule, it moves the execution of the process Instance from the IPC thread pool to the Async thread pool.

 

 

 

 

Be the first to reply!

Reply