Is there an easy way to get Apache Tomcat to reboot automatically after a deployment?

Question

Our project uses Cruise Control to both build and hot deploy a web application to a remote server (via FTP) running Tomcat in the form of a .war file. Unfortunately, "hot" deploys don't appear to work properly, causing us to reboot Tomcat in response to each deployment. We would really like to do this auto-magically, much like the build itself. Is there an easy way to do this?

Side note: both machines are running Windows (XP or server, I think).

Side note 2: Performance doesn't really matter. This is an integration box.

Answer 1

if you have regularly scheduled builds you could easily put something in the cron like this

crontab -e

then stop tomcat at say 1:30 am

30 1 * * * ./path_to_tamcat/bin/catalina.sh stop

then start it up again 2 mins later

32 1 * * * ./path_to_tamcat/bin/catalina.sh start

granted this isn't the best for irregular deployment, but you could easily have regular deployment with scheduled restart.

Answer 2

It sounds a bit to me like you are using the little Tomcat deployment manager thing. I basically have no experience with that, just so you know. That said, where I work we use two settings.

In the server.xml file, the context has the attribute reloadable="true".

All we have to do is place the WAR file in the right spot and Tomcat unpacks it and reloads it, no problem.

Now when I looked it up, the official configuration reference says:

"This feature is very useful during application development, but it requires significant runtime overhead and is not recommended for use on deployed production applications."

Like I said, we've never had problems. Our systems process a large number of requests and we don't seem to have a problem. We've never benchmarked the two configurations against each other though.

You might want to give it a try. At least you would learn if it is happy enough to reload things when done that way. You can check the performance as well to see if it's a problem for you.

I should note that every once in a while things just don't go right and we have to restart Tomcat anyway, but that's relatively rare.

If this works, all you need to do is have a script copy the WAR in the right spot and monitor to make sure things work. After enough deploys Tomcat will run out of permgen space, so you have to be aware that you might need to restart Tomcat by hand anyway.

Other random guesses:

1. Are you FTPing directly into the final WAR location? Maybe Tomcat is just trying to open it too early?
2. Are you getting any kind of error message? Maybe that could help you track the problem down?
3. Have you tried other versions of Tomcat (if available to you)? Maybe 5.5 doesn't have the problem (or 5.0 if you're on 5.5)? Maybe just a newer point release?

Answer 3

If you look at the tomcat startup and shutdown .bat (or .sh) scripts in the bin directory, you will see that they actually run a java process to start tomcat or in the case of shutting down, connects to tomcats shutdown port - see server.xml in the conf directory. You could configure your build ant task to invoke the tomcat jars in the same way as the scripts do.

Answer 4

What version of tomcat are you using? What exactly happens to make it appear as if a "hot" deploy doesn't work?

Answer 5

Is tomcat registered as a windows service?

If so, just write a .bat script using netstart and netstop and have the called as the last step of your deployment process.

Answer 6

reloadable="true"

does not enable re-deployment of war-files (this will work automatically), it enables monitoring of changes of files in WEB-INF/classes and WEB-INF/lib, which is probably not what you want.

Most of the time when re-deployement of war-files in Tomcat freezes, I was able to trace it back to classloader leaks, see see Classloader leaks: the dreaded "java.lang.OutOfMemoryError: PermGen space" exception

Answer 7

You didn't give much detail why your hot deploys "doesn't work properly", but if it's actually been caused by a resource in /WEB-INF/lib been locked (which is not an uncommon cause; you see this often with the mail.jar of the JavaMail API), then just set the Context's antiResourceLocking attribute to true. Here's an example how the webapp's /META-INF/context.xml would look like:

<Context antiResourceLocking="true">
    <!-- Your stuff here. -->
</Context>