Using custom thread names to enhance the debugging of Java applications
JohnPape 0600007J6A Visits (10236)
If you're having some trouble with your Java™ application, be it JSE or JEE, you've probably been looking at javacores (also called thread dumps or java dumps). If not, you should be and that is a topic for another day.
When looking at the javacores with all those threads in there, have you ever wanted to know things like: Which user is causing these threads to spawn? What were they doing in the application? When did that thread get created?
Well want no longer! With a few lines of some very simple Java code you can tack on interesting and very beneficial information to the threads in your javacores. Let’s construct a simple Java application to examine how we can accomplish this.
First, we start with a new class that wraps up a Thread object:
The class ThreadWrapper simply encapsulates a Java Thread object and takes care of the naming of the enclosed Thread object to our liking. You can see above that I've opted to preface threads created by our application with "ThreadWrapper" and then a monotonically incrementing int value followed by a time stamp value created when the ThreadWrapper object was created.
For simplicity in testing let's create a factory-type class that will simplify the spawning of our threads.
ThreadSpawn takes care of the iterations of spawning off the number of threads we want to create. Notice that the ThreadSpawn class takes a Runnable type in the spawn() method. This is the class that encapsulates the work to be done on the newly spawned thread instances. Here's the work class I created for the example.
To be fair, my "work" class is not doing much work is it? Still, the end result is that the SomeWork class will tie up a new thread for some length of time that we will specify. Now, let's tie it all together with a class with a executable class.
The Threader class simply creates an instance of itself, spits out some debug information to the standard out stream and then utilizes our ThreadSpawn class to setup and set the new threads to doing their "work". Now if we JAR up our classes and run our test application with a command line like:
java -jar Threader.jar 10 30
we can kick off a test creating 10 threads and keeping them occupied for 30 seconds. If we capture some javacores during the runtime of this test we'll see something like this:
In the example above you can see how our threads show up in the javacores. Now consider this: if you placed code like this into a servlet or servlet filter class in a JEE application you could do things like put the user name in the thread name to signify which user request this thread is servicing at this instance. Another example might be appending the requested URI or JSP page to the servicing thread name so you can further track what's going on in the application. The possibilities are near limitless and there appears to be little overhead associated with changing a thread's name. The only consideration you'd need to think over pretty thoroughly would be how to reliably reset the thread name back to it's original state in between requests.
Armed with this knowledge, perhaps you'll be able to close an issue faster by adding key debugging information into your javacores!