Recently we’ve come across a scenario where process developer had added an event catch for TaskCreated event. Event catch was added to an Assign Task step.
See snapshot below for illustration.
Due to this event catch, additional event subscription got created for TaskCreated event, whenever that process step was run. Those subscriptions never got cleaned even after process step got completed (Patches are build to avoid those persistent subscriptions – see solution below).
TaskCreated event gets fired every time a task (e.g. user assignment task) gets created in LiveCycle.
For a LiveCycle implementation which generates lot of tasks (multiple processes each with multiple assignTask steps) ; could result in lot of event notifications for these additional subscriptions.
Each notification results in a “workitem” that gets stored in LiveCycle database; increasing the load on workmanager which is responsible for distributing these work items causing delays in processing.
e.g. For this customer scenario, we saw that everytime a new task got created, it resulted in 600+ workitems eventually piling up 320000 work items; causing the system to slow down. Symptom we saw was that even after process instances were kicked off, users did not see the tasks in their queues for long time (few mins/ few hours in some cases).
Avoid defining event catch for a generic event types.
“Event catch” is delivered to the step only if the step is running; so in above illustration; TaskCreated events which get generated in different workflows wouldn’t get delivered to “Assign With Event” step, hence “executeScript” step wouldn’t get executed, in that scenario.
Thus removing that event catch would not result in any functional loss.
However, since event subscriptions are persistent, system has to do extra processing of those work items those get created due to event notifications.
Engineering has built a patch “LC_18.104.22.168_QF_1.116” on ES2 SP1 and LC_22.214.171.124_QF_2.87 on ES2 SP2, to avoid persistent subscriptions in such event catch scenarios.