Easier way to collect thread dumps

When I worked at BEA support, we troubleshooted a lot of issues using the thread dumps. There were a couple of problems with them:

• On Solaris/Linux/HP-UP, the thread dumps had to be extracted from the stdout files, which in some cases did not exist (never redirected) and in others were not rotated on restart and therefore had several months of logs (GBs). Either way finding the thread dumps was difficult.
  
• Windows users often just had stdout going to the console and, when the thread dumps were screen-scraped, they got broken up in all sorts of strange locations making it harder to do any automated processing or even a decent pattern search.
  
• When more than one thread dump was required (90% of the cases), it was hard to figure out how often the thread dumps were taken as they did not include a timestamp. At least SUN JVM did not. JRockit and IBM, both had it.
  

Therefore, I am glad to see that it is becoming easier to get good thread dumps. At least for JRockit with the jrcmd command. In fact, the command looks useful for a number of things.

Unfortunately, it is still somewhat hard to do the same with SUN's JVM. They have the jstack command, but it is still not available for Windows.

Of course, with dTrace, thread dumps might become obsolete, but yet again this is only a Solaris 10 option, though there are some rumours of dTrace for BSD or maybe even Debian.

In a short term though, if you find yourself in need of some serious thread dump taking, do take a look at JRockit. It is free after all. And it does have other cool troubleshooting tools.

BlogicBlogger Over and Out