Question
Requestor already has the lock
Dears,
I have a particular entry in pr_sys_queues whose content when checked it says that it is due to another requestor already has the lock.
Cannot obtain a lock on instance XXXX-WXX-CX IFM-698636, as Requestor BF80544A1738726E72AA5665F5A602E51 already has the lock
But i am unable to find such a requestor in the AllLocks page.
Due to which the entry in pr_sys_queues goes on retrying now with this message.
How is this possible. Share your inputs.
regards,
Jagan
Yes its indeed a queue created for the agent to process.
We have set up three standard agents which work on these entries in table to enable faster processing. So only these three could use them.
Could it be possible they are interfering with each other ?
If you have the 'Auto queue management' option checked for the standard agents then I would not expect them to interfere with each other. How is the queue item being created? If you are using Queue-For-Agent in an activity, there is a 'Deferred' option that can be used so the queue item is not created until the next commit. This can help prevent scenarios where the queue item is committed before the processing is complete on the work object. This could apply if you are creating the queue item from another agent process and the the MinimumAgeforProcessing is set to such a value that the queue item could be picked up right away.
What happens to the queue item if the minimum age of processing of it is exceeded. Does Pega OOTB handle it automatically for another retry ? or is it made into broken ?
The minimum age for processing determines when it should be picked up and processed. Once it has reached that date/time, then the agent should process the item. If there were a failure processing the item, then it would go to the broken queue.
The requestor ID starts with a B so that means it is a batch requestor or agent that has the lock. How is the queue item created? Are there other agents or batch processes that would be processing the item?