Details

Thread Deadlocks are a possibility in any multi-threaded Java application. They can be very difficult to fix and nearly impossible to reproduce in most real-world applications. This is because of the fact that the more threads in use, the more likely it is for a deadlock to take place. A developer can have a very difficult time tracking down not only where the dead lock took place, but also the combination of events that lead up to it.

If you wish to learn more about this feature, please check our technical section.

In normal operation, the Wrapper pings the JVM once every 5 seconds to make sure that its process has not frozen up. The ping timeout is the amount of time to allow for a response from the JVM before the Wrapper assumes that it is hung and restarts it.

The Java Service Wrapper is able to detect most JVM freezes very quickly and restart the application. A report of what happened is generated and sent, so a human administrator can double check to make sure everything is working correctly.

How does the Java Service Wrapper detect a JVM freeze? Please take a look at our ping timeout property page. Because every Java Application is different, these parameters can be configured or disabled.

If you wish to learn more about this feature, please check our technical section.

The Wrapper constantly monitors the JVM process and is able to instantly detect if the JVM process crashes, and then restart it to minimize downtime. By default, the Wrapper will wait for 5 seconds before automatically relaunching your application.

The length of this delay can be tuned to meet your needs, but is recommended to make sure the OS has time to free up any memory or other resources that were associated with the crashed JVM. Please see the wrapper.restart.delay property for more information.

If you wish to learn more about this feature, please check our technical section.

The Java Service Wrapper provides a way for a Java Application to request that its own JVM be restarted. This can be useful in a number of cases. Applications may wish to restart after having had their configuration files modified. Or the application may simply need to be restarted to avoid problems with a memory or resource leak of some kind.

JVM restarts can be triggered from within the JVM by making a call to WrapperManager.restart(). For more information, please check our Java API documentation. There are also more passive ways to trigger restarts. For more information, check our Introduction Page.

If you wish to learn more about this feature, please check our technical section.

Emails can be sent out with a customized message, along with a fragment of the Wrapper's log file. This makes it possible for a system administrator to decide whether or not it is necessary to take further action.

The Wrapper is able to send out alert emails to in response to certain events. For examples and more information, please check our Event Mails Documentation Page.

If you wish learn more about this feature, please check our technical section.

Filters are a very powerful feature which makes it possible to add new behavior to existing applications without any coding. It works by monitoring the console output of a JVM for sequences of text. When they are found, any number of actions can then be taken.

System commands, including external scripts, can be executed in response to any event. These can be useful for doing system cleanup, sending out notifications, or taking actions which can only be handled natively. Adding a filter is easy, you only need to specify a trigger and an action, and you can set up as many as you want. If you want to learn more about our filter system and a list of possible actions, please see our filter property page.

The Wrapper uses various timeouts while monitoring the JVM. Whenever a timeout exceeds, the Wrapper can take actions or force the JVM to go to the next state. Most of the timeouts can be configured to values that let the Wrapper know the expected time needed for your application to start, stop and respond in normal situations.

In some rare cases, however, you may want to execute long blocking tasks from your Java code, which would temporarily make the JVM unresponsive. In order to prevent the Wrapper from detecting this as a JVM freeze, it can be useful to suspend the timeouts before starting the task and resume them once it is completed.

This can be achieved in versions 3.5.40 and above, either by using the command file, actions triggered by filters, timers, deadlock checks, or from the Java code by using the new WrapperManager.suspendTimeouts() and WrapperManager.resumeTimeouts() methods.

Please check the above links for details on your preferred way to suspend/resume timeouts.