Express (Distributed operating systems), v8.0 > Troubleshoot and support > Analyzing application server Java system dumps with the IBM Monitoring and Diagnostic Tools for Java - Dump Analyzer
Write a new analysis module or script
The aim of the Dump Analyzer is to provide an environment for running analysis modules such that a large amount of the environment setup is already done. We assume that a system dump has already been produced from the JVM and formatted with the jextract utility. The Dump Analyzer initially chooses an appropriate image factory which will first read the formatted dump and then read the file to create a DTFJ Image object describing the contents in memory. It then builds a separate analysis context for each of the possibly many Java runtimes in the dump. Finally it chooses a specific analysis module to run in those contexts. When an analysis module is running it has access to the entire DTFJ Image but in particular has access to the specific Java Runtime that it is analyzing. In addition it can make use of various facilities for generating reports, reporting progress and reporting errors. There are also a number of utility classes available to make the task of writing an analyzer simpler. Over time we expect the number of these utility classes to increase as analyzers are written and the useful infrastructure is factored out.
There are three sorts of analysis modules that you might want to build. The first is a module which runs and reaches a conclusion about the contents of the runtime it is analyzing. Possible conclusions might be "the JIT is active", "there are deadlocks", "this dump was caused by an application error" or "this dump contains WebSphere classes". The second type will produce a report describing some details about the contents of the Image. These reports are intended for use by someone attempting to diagnose an application failure. The reports may of course contain messages warning about potential problems as well as listing the contents of the dump.
Typically, the conclusions made by the first type of analysis module are then further examined by another analysis module that attempts to diagnose a particular failure or recommend a course of action. Ultimately, you should be able to produce recommendations along the lines of the following:
- If the dump was caused by a protection fault...
- ...and the current thread was in native code...
- ...and the current native code was in the package
com.acme...- ...then the recommendation is that you should contact ACME Industries for further analysis.
These sort of rules can be written in a form of scripting language provided as part of the Dump Analyzer. These scripts are the third type of analysis module. The scripting capability is deliberately designed to be simple and without looping constructs. Within a script it should be possible to request specific analysis actions and then write out some conclusions. The analysis modules and report modules which involve interaction with the Image object should be written in the Java language.