Question
DXC Technology
BE
Last activity: 7 Aug 2018 9:13 EDT
Requestor pool getting filled repeatedly
Dear,
There were few messages in the logs showing that the requestor pool is timing out due to the max active requestor having increased than the one configured.
Subsequently i tried to clear out the requestor pool.
After that i found in the logs few messages stating that few transactions timed out waiting for lock : ORA-02049: timeout: distributed transaction waiting for lock
Thus i deleted all these transactions also from pr_sys_locks table.
But still the message seem to be coming back to the requestor pool every time i do this.
Is there a way to stop this taking into considerations the messages are poison ones and since it is lower environments do not really care about them.
regards,
Jagan
II
Accepted Solution
DXC Technology
BE
Seems like it was a fix inside the activity referenced in the package. Once corrected, stopped listener, cleared any pending requestor in requestor pool, cleared queues of any poison messages and restarted listener and the problem didnt surface back.
DXC Technology
BE
I did delete the pzinskeys entries in pr_sys_locks table that showed up in the logs but not the entire table, but once i deleted all entries and the pool was empty, it still gets created with a new pzinskey and starts piling up. Did do a restart with marker clean up . Is full table truncate of pr_sys_locks necessary ?
PRPC Version is 7.1.8
DXC Technology
BE
[8/3/18 11:02:41:030 CEST] 00000017 SystemOut O 2018-08-03 11:02:41,030 [stenerThreadPool : 0] [ STANDARD] [Implementation:01.56] ( internal.services.ServiceAPI) ERROR JMS|ReceiveNotifications|ReceiveNotifications|ReceiveNotifications|A58F39374283FA0912BEE65EFED18B665 - JMS service [ReceiveNotifications][ReceiveNotifications][ReceiveNotifications] failed:Database-General A commit cannot be performed because a deferred save of instance XXX-DATA-COLOGGING-VVV EF1DD686-2FC1-4F47-98EF-D1C2763E200C failed :com.pega.pegarules.pub.database.DatabaseException: Database-General A commit cannot be performed because a deferred save of instance XXX-DATA-COLOGGING-VVV EF1DD686-2FC1-4F47-98EF-D1C2763E200C failed
From: (A58F39374283FA0912BEE65EFED18B665:ReceiveNotifications)
Accepted Solution
DXC Technology
BE
Seems like it was a fix inside the activity referenced in the package. Once corrected, stopped listener, cleared any pending requestor in requestor pool, cleared queues of any poison messages and restarted listener and the problem didnt surface back.
Pegasystems Inc.
GB
It looks like the issue is JMS related. Is JMS MDB used and if so which application servers is it running on? Has the JMS MDB been configured with Container Managed Transaction with XA driver?
Simon
DXC Technology
BE
Dear,
Yes the MDB is configured with container transactions.
The thing is i want to know from which table from pega database does pega populate the requestor pool since if i delete this entry from that table i might be able to prevent the looping of this transaction.