Posted: 14 Aug 2015 9:32 EDT Last activity: 18 Aug 2015 4:22 EDT
SendCorr agent causing Rollback to a workobjects
We are facing a weird issue in our production environment.
The issue is that agent execution is causing workobject to rollback if the workobject is submitted and agent execution happens in parallel.
The scenario is; in one of wrapper flow a correspondence is queued to be sent, however the object locks remain with the user. Now the user submits the request which goes into one of the subflow to a workbasket assignment. The Workbasket assignment is created and pxflow is appended with the new subflow details(as expected), however if parallel execution of agent happens, and agent cannot get the lock the system rollbacks the workobject and the newly appended page in pxflow is deleted. so we are havening a stale assignment with no flow and hence the user is getting Error: Flow removed error on the assignment. Also, the audit history captures the flow execution and does not rollback. The weird issue is nothing comes up in log for this issue, also not all users get the issue, only the ones which processes the request quickly in 1-2 mins and agent is coincidentally running in parallel.
Has anyone encountered similar issue or problem? Please share your thoughts and knowledge.
Depending on your Pega platform version number, you may want to try searching for maxlockattempts in your prconfig.xml to make sure you only have it in there once, or add it if it's not there, and set it specifically with this syntax :
<env name="database/maxlockattempts" value="1"/>
The other thing is to check your code carefully and make sure you don't do any "commits" during flow processing, and don't use obj-save with "write now" on your work object or assignment. Instead, rely on the out-of-box saves and commits that normal flow processing offers. /Eric
Thank you for the response and apologies for not responding promptly. We are using PRPC v6.1 SP2.
Also, thank you for suggesting the options. I can confirm that we are not doing any explicit commits or using any obj-save with 'write-now' during our flow processing where the system is failing.
However, I can confirm that this is a very particular scenario, where there is a custom utility which queues the correspondence to be sent and there is no assignment before going to other subflow, which does not yet exist on pxFlow, and in between if the Agent picks up the correspondence from the queue and while lock is held by the user and user submits while agent processing is in-progress, the rollback on flow processing happens. As this is a very rare occurrence, its hard to replicate.
Also, I will give it a try and test the system by setting the maxlogattempts value in prconfig.xml .
Posted: 5 years ago
Posted: 17 Aug 2015 10:45 EDT
Mike Townsend (MikeTownsend_GCS)
Director, Software Solutions Engineering
If you're on 6.1sp2, then max lock attempts won't matter because I'm fairly certain it wasn't added to the product yet. Do you get items in the broken queue? Is it the user's session that rolls back or the agents? If you open the work object from the database, does it contain the data from the other requestor? My guess is that you managed to get into a state where flow processing thought the active requestor has a lock but the other requestor picked it up so when the active requestor goes to save the save fails and the process engine rolls back the entire transaction so that you aren't doing any sort of partial commit. If you can identify why it's all happening, then you can come up with a mitigation plan.
I was referring to the 'Configuration Settings Reference Guide' available on pdn, link: https://pdn.pega.com/node/9699 . I assume this guide is for all 6.x versions as per the document.
I verified the work object and assignment data in database and can see that the its contains data of business user and not the system, and there is no broken queue for this particular work object, I assume it was picked up after the user released the lock. This issue is kind of getting complex as we dig into. I will give it a try by changing the prconfig.xml file to set max lock attempts and see if we can fix this one.
Please recommend if there are any more options which we can try.
Posted: 5 years ago
Posted: 17 Aug 2015 13:51 EDT
Kurt Waltz (KurtW_GCS)
Principal GCS Solutions Engineer
The behavior you're seeing sounds very similar to the behavior addressed by HFix-9336 in Pega Platform 6.1sp2. This fix is not published on Hot Fix Self Service, so I would recommend reaching out to the Global Customer Support team to evaluate if this fix looks like it is applicable to your scenario. If it is, the fix can be provided along with installation instructions.