News: Thread dumps as XML
Alexandre Rafalovitch talks about how thread dumps look different between the various JVMs, and within versions of the same JVM.
Most commercial tools work with the JVMPI debugging interface to access thread information.
Alexandre proposes that we standardize an XML Schema, and allow thread dump generation to this One Format. This would allow tools to work with thread information at a later date, and would allow simple debugging devices such as XSL.
"By converting the various thread-dump formats into the unified XML format, we can increase portability of thread-dump analysis knowledge and visualize the relations previously hidden in the bulk of data. Additionally, as there are more XML/XSLT tools and experts than Java thread-dump experts, many more people can contribute to creating useful statistics and visualizations."
Read Looking at Thread-Dumps
- unified format does not have to be XML by Konstantin Ignatyev on March 09 2004 11:54 EST
- I agree by Paul Kukk on March 11 2004 13:37 EST
- Disagree by David Waddell on March 15 2004 08:18 EST
- Comments from dev2dev article author by Alexandre Rafalovitch on April 01 2004 18:59 EST
I would agree with value of unified format but please leave XML alone.
Look how nice the conclusion looks without XML: By converting the various thread-dump formats into the unified format, we can increase portability of thread-dump analysis knowledge ...
I believe creating the thread dumps into a unified format such as XML will allow us to share that information in a more proficient manor. XML would work perfect in this instance. Allow us to create multiple formats of the dump easily. Another plus point to the XML approach is that reading the thread dumps ourselves would be quicker and more descriptive.
Does anybody know a tool/library that can be used to convert the thread dump (txt) into a well formed XML document?
Backing up the first comment,
this really shouldn't be in xml.
A standardized txt format would suffice;
those that wished to convert this to an
XML format could do so.
Introducing a dependency on xml into
the JVM is an unnecessary step.
Introducing a dependency on xml into the JVM is an unnecessary step.
No one's requesting that package java.lang depend on package org.xml. Using String.class has always been sufficient to compose an XML document.
I had written the original article and just wanted to comment on the discussion so far.
1) Tool availability: There was a slight problem with dev2dev and the tool was not linked in. You can down download the tool from the article link.
2) Dependency: I am not advocating for XML format to be a default JVM output. That would not be efficient to generate and complex to implement. Additionally, different JVMs expose different attributes of their threads (e.g. thin thread id). Even if multiple vendors agreed to use the same format, they are then stopped from adding new information easily. And I would prefer more unstructured useful information in the dump, rather than less of the slightly more useful one.
3) XML or not XML: The problem with universal structured text format is that its ultimate target is human. Which is fine if you can identify all the dependency by eyeballing the text, but if you want to get a small subset of information only (e.g. deadlocks), you are back to trying to reparse the text (manually or automatically). One of the scripts I have, does generates the plain text form. So, if you really don't want to deal with it, treat the tool as black box (with xmlstarlet thrown in) and delete the xml after doing two step generation into the text. And finally, just a thought experiment. What happens if we do define a universal text format, develop the tools to work with that and then a JVM (e.g. JRockit) introduces a new thread status such as 'time-in-waiting-state'. Do we ignore it, even though it would be extremely useful? Do we introduce it as an optional component in the text format (complicating and breaking the parsers) or do we add it into the text format as compulsory element with a default value (breaking all existing parsers again). With XML, you could add the new attribute or even element and most of the scripts will ignore it until you have time to fix them.
Hope this makes my point of view a bit clearer. Additionally, I am scheduled to present at JavaONE 2004 on how to troubleshoot the application servers using the thread dumps. I will be using my tool there, possibly with some additional scripts.
I have seen a tool that uses a different approach. The Stack Trace tool from http://tmitevski.users.mcs2.netarray.com exports the thread dump information to any Java IDE supporting JPDA debugging. For some JVMs it exports the monitor information too. This way you can use the Threads and Monitors view in Eclipse to detect deadlocks for example. I personally like this tool because it can get thread dumps from Windows services and programs started with javaw.exe.