Thread Dump JSP in Java 5 by Dr. Heinz M. Kabutz (JDK version: JDK 1.5 )

Abstract:
Sometimes it is useful to have a look at what the threads are doing in a light weight fashion in order to discover tricky bugs and bottlenecks. Ideally this should not disturb the performance of the running system. In addition, it should be universally usable and cost nothing. Have a look at how we do it in this newsletter.

Thread Dump JSP in Java 5

Ten days ago, I received a desperate phone call from a large company in Cape Town. Their Java system tended to become unstable after some time, and especially during peak periods. Since the users were processing millions of dollars on this system, they should be able to log in at any time.

We managed to solve their problem. As you probably guessed, it was due to incorrectly handled concurrency. I cannot divulge how we find such problems or how to fix it, that is our competitive advantage. Contact me offlist [http://www.javaspecialists.co.za/contact.jsp] if your company has bugs or performance issues that you cannot solve and where an extra pair of eyes can be useful.

One of the measurements we looked at was to inspect what the threads were doing. In this case, it did not reveal much, but it can be of great value in finding other issues. For example, at another customer, we stumbled upon an infinite loop by looking at what the threads were up to.

There are several ways of doing that. If you are using Unix, you can send a "kill -3" to the process. With Windows, CTRL+Break on the console will give you that information.

This server was running on Windows (don't laugh). The application server did not allow us to start the JVM in a console window, which meant that we could not press CTRL+Break.

Another approach would have been to painstakingly step through the threads with JConsole. That was not an option to me.

One of the annoying parts of the typical thread dump is that the threads are not sorted, so it becomes a bit tricky to group them. It would also be nice to see a summary of the state in a table, to make it easier to find problems. In addition, we should be able to copy the text and diff it to see how things change between refreshes.

In good OO fashion, we separate model and view. Let's first define the model:

package com.cretesoft.tjsn.performance;

import java.io.Serializable;
import java.util.*;

public class ThreadDumpBean implements Serializable {
private final Map traces;

public ThreadDumpBean() {
traces = new TreeMap(THREAD_COMP);
traces.putAll(Thread.getAllStackTraces());
}

public Collection getThreads() {
return traces.keySet();
}

public Map getTraces() {
return traces;
}

/**
* Compare the threads by name and id.
*/
private static final Comparator THREAD_COMP =
new Comparator() {
  public int compare(Thread o1, Thread o2) {
    int result = o1.getName().compareTo(o2.getName());
    if (result == 0) {
      Long id1 = o1.getId();
      Long id2 = o2.getId();
      return id1.compareTo(id2);
    }
    return result;
  }
};
}

We also write a bit of JSP, making use of the Expression Language ${}.

    <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Thread Summary:







  






  
Thread
  
State
  
Priority
  
Daemon
    
${thr.name}




    
${thr.state}




    
${thr.priority}




    
${thr.daemon}




  

Stack Trace of JVM:
${trace.key}
       at ${traceline} 

This will generate first a summary of the threads with hyperlinks to the individual stack traces. The summary shows the state of each thread.

Have a look at a sample snapshot [http://www.javaspecialists.co.za/samples/sample.htm(l)] .

A word of warning: you should not make this JSP page publicly accessible on your server, as it opens up the guts of the app server to the general population. Even if they cannot change the state of the threads, it might be bad enough for them to see what methods are being executed.

You might have to change the GET_STACK_TRACE_PERMISSION setting to allow yourself access into the application server.

This is a took that I will keep handy whenever I do performance tuning or difficult bug fixing on a J2EE server running Java 5.

I look forward to hearing from you how you expanded this idea to make it even more useful :)

For those of you lucky enough to be at the JavaZone conference this week, do come and say "hi" to me :) It would be great to meet you.

Kind regards

Heinz

(http://www.javaspecialists.co.za/archive/newsletter.do?issue=132&print=yes&locale=en_US)