...
However, there may be times when you want CAS to start with an empty ticket registry, or when you are upgrading from one version of CAS to another and the Ticket objects may not be compatible. When this is true, any files in the work directory should be deleted before restarting CAS. This is a "cold start". When the CushyTicketRegistry discovers that it has no prior checkpoint file it enter the "Cold Start Quiet Period". For 10 minutes (you can change this in the source) a node will not communicate with any other node in the cluster. It will not send or process notifications and it will not read or return checkpoint or incremental files. This gives machine room operators time to shut down all the CAS servers, delete the files, replace the CAS WAR, and start a new version of CAS with a clean slate. If operations cannot complete this process within the Quite Period then CAS will continue to function, but it may log I/O error messages from the readObject statement if a node tries to restore a checkpoint or incremental file that contains incompatible versions of Ticket objects created by a different version of the CAS code. As soon as all the nodes have been migrated to the new code the error messages go away and Cushy will not have been affected by the errors.
While each node has a copy of its own files, all the other nodes in the cluster have replicated copies of the same files. So if a node fails hard and you lose the disk with the work directory, you can recover the files for the failed node from any other running CAS node in the cluster. Unlike the ehcache or memcached systems where the cache is automatically populated over the network when any node comes up, copying files from one CAS node to another is not an automatic feature. You have to do it manually or else automate it with scripts you write based on your own network configuration.
...