Support Article

Slowness issues with Pega 7.1.7

SA-34960

Summary



Pega slowness Issues recurrence very frequently


Error Messages



------------------------------------------------------------
Locked synchronizers: count = 1
- java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@513bd8ad

-----------------------------------------------------------
com.pega.pegarules.pub.context.RequestorLockException
com.pega.pegarules.pub.context.RequestorLockException: Unable to synchronize on requestor HDF9897F27DAB335A54EC854CDD0412BD within 120 seconds: (thisThread = [ACTIVE] ExecuteThread: '11' for queue: 'weblogic.kernel.Default (self-tuning)') (originally locked by = [ACTIVE] ExecuteThread: '12' for queue: 'weblogic.kernel.Default (self-tuning)') (finally locked by = [ACTIVE] ExecuteThread: '12' for queue: 'weblogic.kernel.Default (self-tuning)')


Steps to Reproduce



Not Applicable


Root Cause



Unable to synchronize requestor within 120 seconds” in PRPC taking long time for the threads.
“Requestor” is a Pega term. It represents individual users or external systems that connect to Process Commander. Requestors are java objects that live within JVM. Each unique user is represented by a requestor object in JVM. Each requestor object contains most of the information, “clipboard” for example, for one particular user.

When one user clicks a button or clicks a link on the client side, http requests are generated and sent to the PRPC server. The web container retrieves one thread from its thread pool to handle each http request, process it, and generate an http response. As you can easily see here, these threads need to access/update the Requestor object during the process. Because one user can generate multiple http requests from the client side, multiple threads may need to work on the same Requestor object. Therefore, these threads must be synchronized on the Requestor object.

Pretty much like how synchronized method in Java works, in PRPC application, each thread must seize the lock of requestor first, work on the requestor; generate response, then release the lock. At the same time, those threads that want to work on the same requestor must wait. If one thread has waited for more than 120 seconds but cannot get the lock, it will quit, and leave an error message “Unable to synchronize on Requestor XXXX within 120 seconds”

This happens often. For example: A user may click a link to generate a huge report, which could take a long time, or use a connector to call an external program, which may take more than 120 seconds, or a thread holding the lock may hang and never release the lock for some abnormal reason. Also it is understandable that when system performance is slower, such errors appear more frequently.

Generally speaking, you can ignore “unable to synchronize” error unless its reappearance hinders effective work.

This may also occur when there is heavy processing going on at the database server (examples like taking backup, email scanning etc) This may cause database operations to last 2 minutes, causing PegaRULES to terminate the requests. Thus, if you experience such problems in the future, take a look at PAL and examine where possible performance bottlenecks are coming.

Resolution



Please identify when these error’s are occurring more frequently and see what are the bottle necks and fine tune to improve the performance of those issues.
The work around is to clear the cache and thus issuing a new request so that new resources are given to complete the task in a second try.


Published March 14, 2017 - Updated April 22, 2017

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.