View from the Trenches: Looking at Thread-Dumps, by Alexandre Rafalovitch

Alexandre Rafalovitch, a BEA Backline Support Engineer emailed me about reading thread dumps and his proposal for formatting dump data. I've read through Alexandres article, and while I'm not a big fan of using XML for everything, he definitely presents an excellent view on making thread dumps easier to read and diagnose. The really cool part is that Alexandre has written an application which takes standard thread dump data, converts it into XML, then uses XSLT to convert the data into the format of your choice.

I'm actually a bit surprised that there isn't a JSR in progress to address this issue. I think one of the reasons for this is that most developers and users are not interested in the nuances of thread dump readability. Of course, as backline engineers, this topic is near and dear to myself and Alexandre. Alexandre will be presenting this in a session at JavaONE 2004, session TS-1646. I'll be sure to attend.

"What would be a perfect solution here is to be able to convert these thread-dumps into some sort of intermediate structure/language that has flexible structure, can tolerate missing fields, and can be processed by third-party tools in various ways. And, of course, if it can somehow involve a currently popular technology, so much the better.

Do we have such an intermediate language? Indeed we do — it is XML. It is somewhat human readable, has many tools written for it, and already has not one but several transformation and reporting technologies built on top of it, such as XSLT, XQuery, and XDB."
[full article]
Comments:

For me personally, I'd rather see more time and effort devoted to the capturing of thread dumps rather than the formatting. Trying to catch a thread dump at the right time is often tricky (having just spent 6 days trying to get a thread dump right as an application was core dumping the VM with too-deep recursive call), or maybe the application has stderr redirected to /dev/null, etc.. Looks like Java 1.5 has lots of stuff to remedy this already (yay jstack and jinfo!), but that's where I'd rather see the work go in. Perhaps something like -XXThreadDumpDir=/xxxx to define a directory where timestamped files are created containing individual thread dumps, rather then just sending them out the error stream. That would work well with an XML file format as well, because the user wouldn't have to pull them out of the console log, which is always time consuming and annoying. Personally, I'd perfer "grepability" out of the box rather than "xsltability". Grep is universal, xslt tools are not, and probably aren't on my production environment. If the output were consistent, then if I needed xml I could create it (certainly someone could easily enough create a reasonable standard dtd) with a tool like that listed here. But most of the time, I just need to know what's happening in that VM right this moment, and a simple, greppable text format is best for that.

Posted by Rob Meyer on June 09, 2004 at 04:45 PM PDT #

Rob, check out little writeup on Omniscient Debugging. This might help make it easier to backtrack through your application to where it crashed. http://www.unixville.com/~moazam/2004/06/01.html#a20

Posted by Moazam on June 09, 2004 at 04:56 PM PDT #

Oooh, ODB looks awesome. I'll point it at my recent bug (which is now solved) and see what it can come up with.

Posted by Rob Meyer on June 17, 2004 at 11:00 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

moazam

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today