I've been reading about Continuous Delivery and it sounds awesome to automate the deployment process. I've been reading about possibilities how to do this with Java Webapps, but usually it ends up with CI server or maven plugin deploying to Tomcat WITHOUT restarting the Tomcat using Tomcats management API. But that leads to OutOfPermGenSpace issues and so I wouldn't use those solutions for production. In addition it is a hassle to kill an out of control Tomcat.

Is there any technology that would make it easy to deploy Java web apps to production? I use maven to build my artifacts and deploy to nexus repository.


I'm not trying to find ways to prevent Permgen space issues. I'm trying to automatically deploy to production. There should be no manual steps beyond choosing a version and clicking a button(or giving a version number to a commandline script). I want to find out if I have to create this kind of setup manually, or if there is a ready made solution for this. Thus far LiveRebel seems to be the only solution so far that doesn't require me to implement everything myself.

  • There are ways to deal with PermGen issues: stackoverflow.com/questions/88235/… – Bernard Dec 11 '11 at 15:37
  • Believe me I've tried to get rid of the issue but none of the solutions have worked. It would be much safer to just restart Tomcat than to try to redeploy. – palto Dec 11 '11 at 15:54
  • Have your script restart Tomcat on a regular basis. – user1249 Dec 14 '11 at 9:46

Disclaimer: I'm an unpaid advisor for their product advisory board.

Zero Turnaround have very low cost products called JRebel and LiveRebel which solve a vast majority of the issues dealing with hot deploying WAR files to a web server such as Tomcat.

As smp7d correctly mentions, JRebel is the development tool version of the two.

They tend to work at the byte code level, avoiding the often broken class loading system in this space.

  • +1 There seems to be an UI for deploying a specific version to production without manual steps. Great. – palto Dec 13 '11 at 12:44
  • Note: JRebel is only meant to be a development tool. – smp7d Dec 13 '11 at 13:54
  • @smp7d - Good point, edited my answer. – Martijn Verburg Dec 14 '11 at 9:41
  • This is for development!! It is not meant for production. And this is not continuous delivery, but hot deployment – Tejas Dec 28 '15 at 9:37

You could restart Tomcat and be done with it. Also, Tomcat 7 has supposedly solved PermGen issues... although I haven't tried.

  • Except how do I automatically restart Tomcat? – palto Dec 13 '11 at 12:46
  • Tomcat, as downloaded from Apache, can be restarted using $TOMCAT_HOME/bin/startup.(sh|bat) and shutdown IIRC. If you are using a Linux distro's Tomcat or similar, you might need to do something else (invoke a /etc/init.d script, perhaps). You should be able to plug that into whatever deployment system you use. – alex Dec 13 '11 at 18:03
  • I already know how to start and stop Tomcat :) So the answer here would be to write a script for the CI that would: 1. Stop tomcat service and clean work directory 2. Copy war to tomcat webapps dir 3. Start tomcat service. I was hoping to find a solution that could do this without me writing such scripts, though it looks like I just might have to. – palto Dec 13 '11 at 19:22
  • Well, you might want to post what are you using for CI- I'm not familiar with them, but someone might be and offer you some help – alex Dec 13 '11 at 21:04
  • @palto, as a developer you should know that the world is never perfect and you need to add a bit of code here and there. – user1249 Dec 14 '11 at 9:47

You should only be doing Continuous Delivery to a development server. Look at deploying changes to an exploded application on this server. If this isn't suitable increase the PermGen size. Schedule daily restarts of the server to clear the memory.

Tag and build a deployment package for the Integration Server and only deploy when requested. This should be co-ordinated with the Integration testing team. I find that more than once a day is usually excessive for this environment.

Deployment of the tested deployment package from the Integration Server to Production should only be done on approval. This usually needs to be scheduled for off-hours.

EDIT: Everywhere I've worked where we had automated deployment it has been hand crafted. There tend to be issues around privileges, approvals, schedules, etc. that might make a generic product not fit well in a particular environment. In environments with multiple load balanced servers, there can be additional issues.

EDIT2: I have always advocated automated deployment. Continuous deployment as I have experience it is build and deploy on check-in. You don't want production to be the deploy target. It is a good way to ensure things build in the target environment and not just on the developers desktop.

Picking off builds as deploy candidates for further testing and possible production deployment is not what I would consider continuous deployment. I do consider it a best practice if the selection and migration is automated

  • This totally depends on the server, the environment, the app, etc. – Dave Newton Dec 13 '11 at 3:54
  • But it should be possible to deploy to production automatically, no matter how many teams you have to co-ordinate with. And isn't deploying rapidly to production the whole point of Continuous Delivery? – palto Dec 13 '11 at 12:45
  • It takes an extremely experienced and disciplined team to safely deploy directly to production. I've lived through a week where production was down because we couldn't get a stable build into production. I didn't get the impression that was the case here. – BillThor Dec 13 '11 at 17:53
  • What does deploying DIRECTLY to production mean? When you have a binary that you are satisfied with you deploy it. I don't mean by Continuous Delivery that you skip testing. Also I've lived through a day where we had a borked release. For the whole day we were figuring out a bug that was caused by mistake in the manual deployment. If we would have automated our deployment and TESTED it on production like environment we could have prevented that. We tested the manual deployment but still made a human error when deploying to production. – palto Dec 13 '11 at 19:17

I think you could increase the PermGen szie(-XX:PermSize=64M -XX:MaxPermSize=128m),this default value is 64M. If you do not want to increase it ,you may be could use ANT to deploy your web app.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.