Create JVM thread dumps and heap dumps from running sMash application
Posted by gregsmit on January 9th, 2009. Other posts by gregsmit
Ever have one of those deadlock bugs that never seem to happen when your application is actually running in a debugger? You know, the kind only happens when logging is turned off, the app is in production, and you can’t ever seem to get the data you need to fix it?
What you really want at that moment is a dump of the whole system state. Well, if you are running an IBM JDK, then you are in luck. There are ways to force both thread dumps and heap dumps of the JVM out to the filesystem. But if you are like me, you usually spend a while searching the web to figure out what kill signals you need to use. That, combined with the way sMash creates JVMs (dynamically, with constantly changing PIDs) and if you happen to be using Windows (which doesn’t have real signal processing) makes it a real pain.
But thanks to the dynamic scripting capabilities of sMash, we can actually add the ability to dump this information directly to our app.
All you have to do is drop a groovy template into your public directory, that will in turn call the dump mechanisms of the underlying JVM.
Create a file in <approot>/public/dump.gt, with these contents:
<html> <head> </head> <body> Forcing heapdump and threaddump <% com.ibm.jvm.Dump.HeapDump(); com.ibm.jvm.Dump.JavaDump(); %> </body> </html>
Now, as long as your application is answering other requests, pointing your browser to the URL http://localhost:8080/dump.gt will create a set of dump files in the root directory of your application. Be aware though that this trick only works on IBM Java runtimes. For other runtimes, similar diagnostics might be possible, but you will need to change the above script to call their dump facillities.
- Greg Smith


January 23rd, 2009 at 5:52 pm
[...] Create JVM thread dumps and heap dumps from running sMash applications [...]