- During intense redeployment (i.e., testing and even sometimes QA or production hot deployments): All of the remote deployment facilities that keep the JVM alive will eventually suffer from the dreaded
java.lang.OutOfMemoryError: PermGen spaceexception if something in the web application is leaking memory.
Most web containers try their best to track down these 'dead' objects and forcefully remove them, but it does not always succeed to reclaim the memory. With a leaking web application, the available memory starts to shrink after each redeploy, and eventually the memory is exhausted.
The only solution to this is to kill the JVM, and restart it. And that is exactly what the Cargo Daemon tries to manage. It will try to shutdown the web application cleanly, but if that fails it will forcefully kill the JVM.
It is the only way to guarantee that a new version of your web application always starts when you want it to.
- In productionheterogeneous environments: With Cargo, the way you configure the container is independent from the underlying server -you can set the different configuration properties, define datasources, add deployables, etc. transparently. You can therefore use the Cargo Daemon as a container-independent daemon, with support for the generation of the proper configuration on all supported containers.
- During upgrades: As Cargo is not dependent on the application server nor on its version, you can easily reuse an existing Cargo Daemon setup to use it for another version of a container, or another container altogether; without having to worry about understanding how to configure it.
Table of Contents
The documentatation for the Cargo Daemon includes: