Debugging Your Java Application using the Wrapper

The Wrapper contains support for requesting that the JVM dump out its current state. The exact contents of the information will vary depending on which JVM is being run.

The Sun JVMs will display the stack traces of all running threads to the console.

IBM JVMs provide even more useful information. The stack traces of all threads as well as object monitor states are dumped to the console. In addition, a file is created in the current directory which in addition to the information shown in the console also contains useful information about the system including all of the environment variables.

A Thread Dump can be requested on Windows systems by pressing CTRL-BREAK or on Linux systems by pressing CTRL-\. Invoking a thread dump does not affect the JVM. It will continue to run normally.

The startup for Linux and Solaris provided with the Wrapper installation, launch the Wrapper in a background thread. To request a thread dump using these scripts, simply rerun the script specifying the 'dump' parameter.

If the wrapper.debug property is set to TRUE, it quickly enable debug logging.

Many configuration problems can be quickly resolved by setting the log level of the console output to DEBUG. The full command used to launch Java as well as version information on the JVM being run will then be displayed in the console. See the Logging Configuration Properties section for more information.

When "include file" (cascading style) in the configuration file is being used, please enable Debug Messages.

If you encounter any licensing problems, please set the wrapper.license.debug property and enable include file debugging. In combination, most configuration problems become obvious.

While the wrapper.java.detect_debug_jvm property is set to TRUE and the Debugger Detection is functioning, the Wrapper will ignore certain timeouts.

CTRL-BREAK can be used to invoke a thread dump when pressed in the console running the Wrapper. This method can not be used to invoke a thread dump when the Wrapper is running as a service.

When running as a service, it is possible to invoke a thread dump by running the wrapper as follows: "wrapper.exe -d ../conf/wrapper.conf". See the following page for details:
http://wrapper.tanukisoftware.org/doc/english/prop-thread-dump-control-code.html

Thread Dumps will always be sent to the JVM'S console, which will in turn be logged to the Wrapper's console and wrapper.log file at a log level of INFO.

@Mrudul Goyal

If my wrapper script is called MyService (.bat/.sh), then you simply call

MyService dump

like you would call
MyService start
MyService stop
etc...

Where does the thread dump to, in my experience, it is the folder where the script actually is located.

The Requesting Thread Dump section fails to explain how one needs to take a thread dump in case of multiple services or for that matter even a single service is running. A proper example would have helped. For example if we only have a service running - how will CTRL_BRK in windows just print a thread dump and where.

Another usefull Debugging technique worked well for me:

Step one: Configure the JVM in the propertiesfile to listen on a remotedebugging port:

# Java Additional Parameters for debugging
wrapper.java.additional.1=-Xdebug
wrapper.java.additional.2=-Xnoagent
#wrapper.java.additional.3=-Xrunjdwp:transport=dt_socket,server=y,address=8000,suspend=n
# or:
wrapper.java.additional.3=-Xrunjdwp:transport=dt_socket,server=y,address=8000,suspend=y

If you enable suspend, the JVM stops and waits for a connection before the serviceapplication starts. If you disable it, the service/application runs normal until a debug client connects and sends breakpoints.

Step two: Connect with your favourite debug client (eclipse in my case) and start debugging.