Creating a Thread Dump in WAS

A thread dump in Websphere App Server is a log file that contains information about the currently running threads and processes within the JVM. A thread dump log is created if a process on an application server spontaneously closes. Thread dumps can also be triggered on command (forced). This is helpful when you have an applicaiton that is difficult to troubleshoot in development, but is regularly crashing in production.

To force a thread dump, do the following:

1. Launch wsadmin from the bin directory.
2. Create a local variable with the following command in wsadmin:
   set jvm [$AdminControl completeObjectName type=JVM,process=server1.*] where “server1” is the name of the actual server you wish to dump.
3. Generate the thread dump with the command:
   $AdminControl invoke $jvm dumpThreads
4. Look for a file in the WebSphere Application Server root directory with a name following the format javacore.data.time.id.txt.

This is valuable data where you can search the data for what went (or is) going wrong in your applications.

• If the thread dump was created by the JVM and was not forced, check for error or exception information strings at the beginning of the file.
• Check the snapshots of the threads. These snapshots start in the section labeled Full thread dump. Look for threads with descriptions that contain state:R. This description content indicates that the threads were active and running when the dump occurred. Also, look for multiple threads with the same Java application source code location. Multiple threads from the same location might indicate a deadlock condition.

Keep in mind that thread dumps are different than heap dumps. A heap dump shows you the memory map of what is currently running. Using a tool like Heap Roots or Heap Analyzer from IBM Alphaworks is very handy at identifying memory leaks and runnaway processes. Of course there is also the Tivoli Performance Viewer built into the toolset. On WAS 7, you have the “Performance and Diagnostic Advisor Configuration” (formerly the Runtime Performance Analyzer) which can give you dynamic recommendations while in flight on production systems. This is incredibly valuable for those bugs/defects which are terribly difficult to reproduce in a development environment. Your IBM business partner should also be able to help you as well. If they can’t, perhaps you should find another business partner who knows what they’re doing.