Not aware of any tools from pega. Generally we always recommend use the native thread dumps generated by the JVM vendor command/tools. Think of pega dump in the log as a notice: something may not be right (common case is performance), generate the JVM thread dumps for pega to analyze, using the tools you mentioned (IBM ISA is a great tool).
Your advice is helpful. Indeed, the Pega dump is proprietary. I was just asking if someone can explain the logic of the format Thread[WorkManager(2)-13,5,JBoss Pooled Threads] : what does 5 main, and what are the other infos for.
Thank you for your answer. Yes indeed, some helpful information is at the end of the dump. In our case, we can see the following ends (where for the first i have the thread reference immediatelly after dump end while for the second it can be found some lines later) :
com.pega.pegarules.pub.context.RequestorLockException: Unable to synchronize on requestor xxx within 120 seconds: (thisThread = http-xxx-8080-3) (originally locked by = http-xxx-8080-1) (finally locked by = http-xxxd-8080-1)
Nope, the issue is still there. we did not truncate the PR_SYS_STATUSNODES table. Before proceeding with that could you please be able to suggest why we should go for this approach and what was the root cause behind this thread dump.