3

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.

Ken Wootton
  • 1,100
  • 1
  • 10
  • 19

8 Answers8

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.

ethyreal
  • 3,659
  • 2
  • 21
  • 25
  • Ah, I should have mentioned the remote machine (and the build machine) are windows boxes. – Ken Wootton Sep 19 '08 at 20:30
  • then you could easily set up the scheduler to to the same thing through task manager, and grab the catalina.bat file i believe – ethyreal Sep 19 '08 at 20:35
  • Thanks for the suggestion. Unfortunately, this is an irregular deployment because it is launched in response to user check-ins via SVN. – Ken Wootton Sep 20 '08 at 00:48
1

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.

Martin OConnor
  • 3,583
  • 4
  • 25
  • 32
1

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.

shsteimer
  • 28,436
  • 30
  • 79
  • 95
0

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?
MBCook
  • 14,424
  • 7
  • 37
  • 41
  • 1) Yes, we do a direct FTP of the file. 2) I don't know of any error messages related to the file. It's just obvious that there is some type of caching going on. 3) We use the latest and greatest version of Tomcat. I hear that we tried reloadable before but we'll give it another shot. Thanks. – Ken Wootton Sep 19 '08 at 20:56
0

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

user17978
  • 11
  • 1
  • 4
  • We are using Tomcat 6.0.18. A hot deploy often doesn't look like a deploy at all. Caching seems to confuse things, for example. – Ken Wootton Sep 22 '08 at 14:51
0

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>
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
0

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

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
0

One way to start the tomcat on the startup is to run it using cron using the @reboot attribute:

open up a terminal and type :

sudo crontab -e

at the end of the file enter the command:

@reboot /`PATH_TO_WHERE_TOMCAT_INSTALLED`/bin/startup.sh

save the file and exit.

The above command will run the command once everytime computer boots up.

Sobhan
  • 1,280
  • 1
  • 18
  • 31