What prompted me to write this bit was a question I was asked by one of our customers: “So stuck threads are a signal that some backend system is misbehaving. How can we monitor the number of stuck threads in WebLogic server?” Searching online, the first few pages in Google come up with administrators asking the same question.
Some solutions offered:
· The WLDF can trigger on stuck threads, so you can have it send you a mail or an SNMP trap, but it’s very limited in functionality.
· Stuck threads can be hogging threads as well and in WLST the total count of hogging threads is an attribute of a server runtime. That’s easily found and manipulated in a WLST script. But that’s not a trustworthy indicator!
· Use jstack, then count the number of “[STUCK]” instances.
Only that last one can be used to build historic data, but even then it triggers on any stuck thread, you have to do a lot of string parsing to count only threads you are interested in.
Strangely enough nobody offered the OEM. Oracle Enterprise Manager can monitor stuck threads and saves historic data and even allows some very cool toolings. But if OEM has a Stuck Threads metric that means there’s also an MBean. And it is, but it takes some digging through the runtime MBean tree. Browsing with WLST, every deployment gets a workmanager and if no specific workmanager is added, a copy of the default work manager configuration is used. And that in turn has a StuckThreadCount attribute.
Here’s a script that counts all of these per server: Read the complete article here.
For regular information become a member in the WebLogic Partner Community please visit: http://www.oracle.com/partners/goto/wls-emea ( OPN account required). If you need support with your account please contact the Oracle Partner Business Center.