What causes a PRPC thread dump?
We occasionally see thread dumps in the PegaRULES log file, which seems to contain a dump of information on each currently held thread in the JVM. What is the trigger that causes PRPC to start a thread dump? Also, is there a method to manually trigger this?
Hello Justin,
Blocked thread count triggers the thread dump.And there are different ways to manually generate thread dump and it depends on the Operating system.For linux kill -9 <process id of JVM> and for windows you can take the thread dump using jvisualvm/JHAT tool.
PRPC is configured to allow a requestor to run a single interaction at a time (concurrent interactions within the same requestor - with the exception of the creation of background/child threads which must be explicitly initialized using the Run in parallel configuration for Connect-XXX rules, or by using java steps to create a BatchRequestorTask, is not supported). So if an interaction takes beyond the threshold time of 2 minutes, a thread dump happens to provide the administrator the context of the threads when this happens. You also get a com.pega.pegarules.pub.context.RequestorLockException in the logs indicating that this requestor is currently blocked.
Hi SrinivasuA,
I believe you can change the threshold; but I wouldn't recommend it - at least not until you understand the exact reason a Thread Dump was triggered in the first place.
Check the Thread Dump in the logs; there is usually a message (just before, or just after - depending on your version) that indicates *which* thread caused the Automatic Thread Dump to be taken.
There will be a 'Locked By' and 'Originally Locked By' string in there are well - which will refer to other threads in the Thread Dump; look at the stack traces for these Threads (quite often they are the same thread, but not always).
The Stack Trace of the Thread that is shown as 'Locked By' (or/and 'Originally Locked By') - can indicate what sort of things were holding up the system (DB, CONNECTOR etc).
You can cross-check with your ALERTs file (using the Requestor ID for instance in the message for instance); and also look what sort of alerts (DB, CONNECTORS etc) are showing up.
If you want GCS to assist with this - open an SR, and provide an example PegaRules.log which contains a Thread Dump; along with with corresponding Alert file.
[LES ManagementDaemon] [ STANDARD] [ ] [ ] (l.context.ManagementDaemonImpl) WARN - Long running request detected for requestor H84F30A84E6B7C76A1D48B85828F6B9B6 on java thread http-nio-8446-exec-14 for approximately 1822 seconds -- requesting thread dump.
Thread dump was generated due to the long running requester. This was identified on the performance testing. We would like to check the configurations for threshold for the long running requester and thread dump generation threshold, will increase the value if required. Do we need to contact GCS for configuration details ?
