A thread dump is a snapshot of every thread that is running in Sterling Integrator at the time the thread dump is generated. The thread dump shows exactly what each thread is doing at the time the thread dump is generated.
You can conduct a thread dump to determine bottlenecks in Sterling Integrator. Typically, problem threads are in a state of waiting. Threads with a state of runnable or R indicate a healthy thread.
For information about the different states of a thread dump, refer to the topic "Reading a Thread Dump".
The subsequent sections describe command-line methods for working with thread dumps. You can also work with thread dumps from the user interface by accessing the JVM Monitor page that is available by navigating to Operations > System > Performance > JVM Monitor.
Note: The JVM Monitor page is available only for Linux, IBM AIX, Sun Solaris™, and HP-UX platforms.
The heap dump option is available only on Linux and AIX platforms.
The JVM Monitor page enables you to:
• Conduct a thread dump.
• Download and delete the dumps conducted from the system.
• Enable GC (garbage collector) output. Enabling causes the GC output to be written into the noapp.log.
• (Linux and AIX only) Enable or disable heap dumps. Enabling causes a heap dump to be generated along with thread dumps.
Note: For the Command Line Adapter 2 (5009 and interim fix 5009_9 or later), when you use Operations
> System > JVM Monitor > Take Thread Dump, the default Command Line Adapter 2 must match the CLA2_PORT in the sandbox.cfg to take thread dumps from the User Interface.
Performing a Thread Dump in UNIX (HP-UX or Sun Solaris) To perform a thread dump in UNIX (HP-UX or Sun Solaris):
1. Access the computer on which Sterling Integrator is installed.
2. Change your working directory to install_dir.
This lists the parent thread process ID.
4. Enter ps -ef | grep noapp.pid.
This returns all the child process IDs associated with the parent process ID.
5. Enter kill -QUIT noapp.pid child.pid.
(You must include both the parent PID and the child PID.)
6. The thread dump is placed in the noapp.log file in the install_dir/logs directory.
Performing a Thread Dump in UNIX (IBM AIX) To perform a thread dump in IBM AIX:
1. Access the computer on which Sterling Integrator is installed.
2. Change your working directory to install_dir directory.
3. In the command line, enter cat noapp.pid. This lists the parent thread process ID.
4. Enter ps -ef | grep noapp.pid.
This returns all the child process IDs associated with the parent process ID.
5. Enter kill -QUIT noapp.pid child.pid.
(You must include both the parent PID and the child PID.)
The thread dump is placed in the javacore*.txt file in the install_dir/noapp/bin directory.
Performing a Thread Dump in Linux To perform a thread dump in Linux:
1. Access the computer on which Sterling Integrator is installed.
2. Change your working directory to install_dir directory.
3. In the command line, enter killall -QUIT java.
The thread dump is completed. Depending on your JVM, the thread dump is placed in one of the following locations:
• noapp.log in the install_dir/logs directory
• javacore*.txt
Performing a Thread Dump in Windows To perform a thread dump in Windows:
1. Navigate to install_dir\bin directory.
2. Run hardstop.cmd command to stop Sterling Integrator.
3. Run start_GIS_console.cmd command from the install_dir\bin directory. It will run Sterling Integrator in console mode.
Running start_GIS_console.cmd command does not start Sterling Integrator services. It will run Sterling Integrator services in a series of command prompt windows, which cannot be closed while it is running.
You can track the progress by watching si_exe.log as running this command takes longer time for Sterling Integrator to start.
4. Perform a thread dump using the following steps:
• Go to the debug_noapp.cmd command prompt window.
• Press Ctrl + Break.
• Open the noapp_exe.log file in the install_dir\logs directory and scroll to the bottom.
• Verify that the thread information is present in the log file.
Performing a Thread Dump in IBM iSeries®
To perform a thread dump in iSeries:
1. Access the computer on which Sterling Integrator is installed.
2. In the iSeries command line, enter WRKACTJOB.
3. Locate the two QP0ZSPWP jobs that are running in Sterling Integrator and note the name of the user associated with these jobs.
4. Press F11 twice to locate the job numbers.
5. In the iSeries command line, enter DMPJVM and press F4.
6. In the Dump Java Virtual Machine (DMPJVM) panel, enter QP0ZSPWP as the job name and user as the user prompt and jobnumber as the number prompt.
7. Press Enter. The thread dump is completed.
8. Repeat step 6 for the second job number.
9. In the command line, enter WRKSPLF and locate the two QDMPJVM spooled files. These files are the output from your thread dump.
Reading a Thread Dump
A thread dump contains the following components:
• List of all the threads running in a virtual machine.
• List of all the created monitors, including the current owner and number of threads waiting for that monitor to be released.
• List of all the special monitors used internally in the virtual machine.
Each thread has an associated state. The following states may be associated with a thread:
• Other than IBM JVMs:
• runnable – Running or executable thread.
• object.wait () – Thread is waiting on a condition variable.
• For IBM JVM:
• R – Running or executable thread.
• S – Suspended thread.
• CW – Thread is waiting on a condition variable.
• MW – Thread is waiting on a monitor lock.
• MS – Thread is suspended waiting on a monitor lock. An MS state indicates a virtual machine error.
The following example shows a thread in a runnable state and a thread in a waiting state:
"RMI TCP Accept-0" daemon prio=5 tid=0x015931f0 nid=0x1a runnable [bbbff000..bbb ffc28]
at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353) - locked <0xcc709620> (a java.net.PlainSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:448)
at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:334) at java.lang.Thread.run(Thread.java:534)
"RMI
RenewClean-[10.117.2.193:58586,com.sterlingcommerce.woodstock.util.frame.jndi.AddrClientFactory@c837cd]"
daemon prio=5 tid=0x00b5f6f8 nid=0x13 in Object.wait() [bc97f000..bc97fc28]
at java.lang.Object.wait(Native Method)
- waiting on <0xcc709728> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked <0xcc709728> (a java.lang.ref.ReferenceQueue$Lock) at
sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:500) at java.lang.Thread.run(Thread.java:534)