App Slowness: Unable to synchronize on requestor
Users report performance problems in a multi-node PRPC environment. Users are experiencing difficulty logging in. Environment slows down, eventually becomes unusable throughout workday. New users are unable to login.
Logged in users report the error on screen: Unable to synchronize requestor.
The Pega Logfile reveals:
Unable to synchronize on requestor H349FA062XYZ0703FBA3327BDB0535B59 within 120 seconds: (thisThread = [ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)') (originally locked by = [ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)') (finally locked by = [ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)')
Note that the Pega ALERT logfile shows large numbers of PEGA0005 alerts, and some PEGA0026 alerts. Initially, PEGA0026 alerts were not deemed threatening because of their small numbers.
Steps to Reproduce
Unable to identify a method to trigger a reproduction of the issue. However, Pega ALERT log time stamps reveal that this issue appears to occur during Agent Processing.
A defect/misconfiguration in the PRPC operating environment.
After resolving the significant PEGA0005 ALERTs in the Alert log, the PEGA0026 ALERTs became even more numerous. As a result, examination of the customer environment revealed that they had not one JDBC JNDI Name (jdbc/pegarules), but THREE (3) JDBC JNDI names. Of greater interest was that only one JDBC JNDI Name (jdbc/PegaRULES) actually had an entry in the WebLogic JDBC Connection Pool Manager - the other two JNDI Names were mapped to custom JDBC Connection Pool Property Definitions (one was mapped in the DATA-ADMIN-DB-NAME class with custom properties; the other was mapped in a custom script embedded in the prweb.ear file).
This issue is resolved through the following local change:
Tune the JDBC Connection Pool properties in both the WebLogic admin console and in the PRPC class definition for the custom connection.
0% found this useful