System Queue management in SMA and pr_sys_queues table
I noticed that the amount of Item Count with Status Scheduled in SMA is very high like and not equal to the count of records in the table pr_sys_queues with column pyitemstatus as Scheduled.
Means my understanding that the table from where this is fetched in SMA is pr_sys_queues is wrong. Could you let me know from which table does SMA populate the details in the section called System Queue Management under Agent Management.
So whatever is related to an agent is only stored in PR_SYS_QUEUES right.
If so, if there is a poison entry in this queue which is trying to kill the server with many retries, is there a way to handle this particular entry. Any best practise ?
We would normally go and update the table's pyitemstatus from Now-Processing or Scheduled to Broken-Process. But after this update, we see that we are no more able to find that entry in the table any more. What happens to it ?
If the item is in a Now-Processing or Scheduled status then it should still be in the table. Is it a custom agent or an out of the box agent? If it is the ServiceLevelEvents agent, those would be stored in the pr_sys_queue_sla table.
It is a standard agent. We are of couse able to see Now-Processing and Scheduled items but the ones manually moved to Broken-Status are not seen after i update them. Why is that. Does Pega clean them ? because we would still need those broken items for more investigation.
I do see some broken items in the queue but those have reached this status after completing their maximum retries. My question is specifically for those that are manually updated to broken by a db script.