Debugging Your Java Application using the Wrapper

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

Oracle 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 launches 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 enables 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.

• wrapper.adviser (3.1.0)

  Displays advice whenever certain common problems are detected.

• wrapper.child.status.loglevel (3.4.0) ( Pro )

  Controls the log level of messages related to the child process management.

• wrapper.console.loglevel (1.0.0)

  Filters messages sent to the console according to their log levels.

• wrapper.java.command.loglevel (3.1.2)

  Controls at which log level the generated command line will be logged.

• wrapper.logdialog.loglevel (3.3.1)

  Filters messages of the log dialog according to their log levels.

• wrapper.logfile.loglevel (2.2.5)

  Filters messages sent to the log file according to their log levels.

• wrapper.ping.alert.loglevel (3.5.16)

  Controls at which log level the ping alert messages will be logged.

• wrapper.properties.dump.loglevel (3.5.30)

  Controls at which log level the configuration properties will be logged.

• wrapper.property_warning.loglevel (3.5.21)

  Controls at which log level warnings about invalid property values will be logged.

• wrapper.syslog.loglevel (2.2.5)

  Filters messages sent to the syslog (or event log on Windows) according to their log levels.

• wrapper.event.default.email.maillog.loglevel (3.4.0) ( Pro )

  Filters messages included in the emails according to their log levels.

• wrapper.event.<event_name>.loglevel (3.3.6)

  Controls the log level of messages being logged each time a specific event takes place.

• wrapper.event.<event_name>.message (3.3.6) ( Pro )

  Controls the message which will be logged each time a specific event takes place.

• wrapper.event.<event_name>.command.loglevel (3.3.0) ( Pro )

  Controls the log level of messages related to the event commands being executed.