Thread Deadlocks are a possibility in any multi-threaded Java application.
They have been a problem since the first multi-threaded applications were implemented.
For example: An application can go through a full test cycle, be released, go through additional testing,
and then finally be deployed for mission critical use.
As the application's usage grows, some critical component suddenly stops responding.
The system administrator's only recourse is to kill and restart the application to get it working again.
What usually follows is that the users of the application complain to the system administrator
about the inconvenience, loss of sales, or other damages caused by the downtime.
The developers of the application are notified that there was an application freeze and told to immediately resolve it.
Unfortunately, there is usually very little, if any, information as to what caused the application to freeze.
Developers need to try and resolve the problem without any clues as to what caused it, or what the problem even is.
This often leads to a "try it again and see what happens" kind of response, which is never good for anyone involved.
When a Deadlock is detected by the Wrapper, it will first log a detailed report of exactly which threads and which objects were involved.
It can then immediately restart the JVM to make sure that your Java Application is back up and running with a minimum of downtime.
This means that not only will your Java application remain operational,
but all of the information required to report the problem, so it can be fixed, will also be available.