Skip to main content


 

 ymptoms

 


More than 2000 process Suspended didn't escalate on time. By searching about the problem we found processes in table Async has escalation Date before The Current Date.

Note 1: There is no users that have alternate working hours in workspace and in addition to this the activity Escalation is configured to ignore Working Hours / Zones:

 

 

 

12198iF857328CC33E83BA.png

Note 2: Escalation emails working fine in Event Escalation.
 

 

Diagnoses

 


For troubleshooting purposes it is possible to check the Async table for escalation records and then set the server ID value to 99 to chick if any specific process instance has the problem
 

 

Resolution 

Check the Async table for records of escalation then set the server id value to 99 to know which process instance has the problem

There process was found to works as expected.

The client used to have 2 K2HostServers running, they then switched one off and only want to use 1 due to configuration.
Based on the amount of GOTO Activity calls they manually make, we recommend they reinstate the second K2HostServer.

 

 



 
Even with 1 K2HostServer running was it still processing the remaining escalations or did it stop processing because the escalations have past the current date? What about increasing the threads?

@PYaoIn this case there was second server in K2 environment to which some of the escalations processing was assigned. Server was removed from environment while escaltion items were still assigned to it. Solution was either to perform Go To operation for each instance affected by server removal, but there were thousand of instance it is probably easier to re-introduce server back to environment so that escalations processed and then remove it again if necessary making sure that nothing is assigned to this specific server.


As for increasing threads it is not relevant here and in general it is never a good idea unless you 100% sure that you understand why you increasing them and there is avsolutely no way to design your process/es and workload so that they are working within default tread pool limits. And even if latter is the case scale out (adding extra K2 server) is a recommended approach as opposed to increasing threads on existing server. In 90% of the cases increasing the thread pool limit to a higher value is just a workaround which hides a real issue which should be resolved in a different way.


Reply