Thread dump in Tomcat

In a multithreaded environment if the implementation is not perfect, then deadlocks are common scenarios. We can analyse the deadlocks by placing log statement at proper locations in the code and analyzing the log, however to exactly pinpoint a deadlock thread dump would be required. Using the thread dump, we can exactly point out what are the two threads which are fighting for the monitor and prints the stack trace of each thread. With the stack trace we can easily find the use case where the deadlock occurs. There are many ways of getting the thread dump and few of them are listed below.

Unix:
Thread dump can be obtained in the appropriate log by sending the command
kill -3 PID, where PID is the process id of the Tomcat jvm.

Windows:
If your tomcat is running as a windows console, then you can open the console and type <ctrl>+<break>. This would print out the thread dump on the console. Make sure you increase the screen buffer memory size to capture the entire thread dump. However If your tomcat is running as a windows service, then you can obtain the thread dump by using the Tomcat monitor.

More on Tomcat as Windows service:
The Tomcat service monitor when started will bring an icon on the system tray. Right click on the icon and select "Thread Dump" in the menu options. This will trigger the generation of thread dump and the thread dump stack trace will be logged to the file system based on the Tomcat service configuration.

With the default settings, the tomcat log redirection would be set to auto. This can be verified by opening the Logging tab of the Tomcat service editor. With the default configuration, the threaddump would be either in jakarta_service, stdout or stderr logs. Or if you have configured tomcat service to redirect to a specific file then you will find the stack trace in the configured file. However if you not configured the logging properly for the tomcat service, then the stack trace would be lost. You will have to configure the service with proper values for logging and restart the tomcat service.

There are also other hacks of sending the <ctrl>+<break> signal to the tomcat service. For instance there is an application called SendSignal.exe which can send <ctrl>+<break> signal to tomcat service by running the command: sendsignal PID, where PID is the process id of the tomcat service. The thread dump stack trace would be logged to file system based the tomcat service configuration. However it may not work in all scenarios based on the security settings. Atleast I couldn't get it working as it always gave me the error related to insufficient privileges, though both the service and sendsignal were run by the same user.

NOTE: sc queryex <service_name> will give you the process id of the service.