Posted: 27 Jun 2019 11:29 EDT Last activity: 23 Sep 2019 14:09 EDT
Pega Proactive Notice: Thread Locking
Environments on the following Pega 8.X releases may possibly experience an issue with user or batch sessions becoming blocked or unresponsive:
All subsequent Pega 8.X releases include mitigation to this potential issue.
How to avoid the issue
To ensure relevant environments do not incur the thread locking issue, it is recommended that all environments proactively enable a defined configuration setting.
This setting must be configured via prconfig.xml or a JVM command line argument. It cannot be set via a Dynamic System Setting.
Steps to Take
To avoid this issue using a prconfig.xml setting follow the steps described in the Modifying the prconfig.xml file Designer Studio Help article to add the below setting to every Pega node/JVM in the cluster:
To avoid this issue through a generic JVM argument add the below string to every Pega node/JVM in the cluster. How to add generic JVM arguments varies between application servers and your environment setup. Contact Pega GCS if you need help.
*IMPORTANT* After implementing the change, an accompanying node restart must be initiated.
If you encounter issues implementing the prconfig change or have questions about it, post your questions below. The Global Client Support engineers in the PSC will answer your questions or determine and advise if you need to go to My Support Portal to submit a Support Request (SR).
There are not, nor are there plans to do so in the future. However, we did recently do a community collaboration to catalog all 7.x critical hot fixes. This provides a single reference for 7.x installs to ensure they are current with the hot fixes Pega has deemed critical for secure and performant deployments.
Let me check into this before providing a definitive response. For now I can tell you that there were none listed at the time we posted this initial draft. It wasn't too long ago, and we do have a recurring action to do maintenance to ensure this list is up-to-date. Let me inquire into this further and if there are any new updates, I'll ensure they get documented and then reply back here.
nice question. No, you won't have to keep this forever. When you upgrade to the next forthcoming patch release, you could then get rid of this setting. Changes have already been made in the 8.1.x & 8.2.x patch release streams so that the next patch releases of those that come out later this summer will make the traditional synchronization policy the default
You only need to change one or the other. Both ways control the same setting. You can choose the one that best fits your deployment. If it's easier for you to change the config file, then do that. Or if it's easier to control command line args, then choose that route
Hello Niladari- We were suggested by one of Pega's performance tuning expert, to remove all the settings out of prconfig file and keep them as DSS's, if any JVM args required, add them at the JVM level.
We havebeen following that approach past one year and our applications running stable. I would suggest to go the same way.
There is an optimistic way to detect DEAD locks by using ThreadMXBean, which provides a method called findDeadLockthreads() which returns id of all those threads which are in deadlock and waiting for each other to release monitor or acquire lock.