Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Most web containers (e.g. Tomcat, Jetty) provide built-in remote deployment facilities already, also many of them already have daemon integrations; so why use the Cargo Daemon?

  • 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 space exception 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 production: 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.

Table of Contents

The documentatation for the Cargo Daemon includes: