Message-ID: <1611990268.100193.1398094495757.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_100192_1417739219.1398094495756" ------=_Part_100192_1417739219.1398094495756 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Tomcat 7 added a superb but rarely used feature, called parallel deploym= ent. With enough memory on the system, you could approach poor man's high a= vailability with parallel deployment but where it really shines is continuo= us integration and continuous deployments to your alpha/QA systems. It comp= letely sucks if your development team/CI system deploys a new version to an= alpha server 60 or more times a day and you need to reload the web applica= tion every time (or worse yet, restart the whole server) while at the same = time, your QA is desperately trying to use the same system to verify featur= es and test user experience. With parallel deployment, existing users can k= eep using the same version of the web application until their session expir= es while others can be simultaneously using newer versions.
However, parallel deployment and tools for it are surprisingly rough on = the edges. I haven't found any Maven plugins that would automatically take = advantage of the feature so I hacked one together, using Ant so those disli= king Maven can also enjoy the feature .
Little convoluted perhaps readable and straightforwarded. The important = thing to note is that Tomcat's parallel deployment feature relies on specia= l naming convention of the war file, with double hash (#) character separat= ing the version from the context/war file name. Above, I'm using the BUILD_= NUMBER variable as generated by (Jenkins) CI system but you are of course f= ree to use any other version identifier, however Tomcat only understands al= phabetical ordering of version identifiers. Another thing to note is that c= urrently the previous versions are not unloaded by default but just passiva= ted. This causes the memory to fairly quickly run out which is why I'm simp= ly manually deleting the previous war files that causes Tomcat to undeploy = and remove their exploded webapp folders. For continuous delivery, you most= likely want to set Host attribu= te undeployOldVersions for removing previous instances, i.e. h= ave something like this in your Tomcat's server.xml configuration file:
Finally one more note about the parallel deployment is that if loading t= he new version of a webapp fails, it'll never become active, so you always = have a version of the webapp in a runnable state.