You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jeff Sturm <je...@eprize.com> on 2011/04/07 18:25:53 UTC

Auto-deploy failure

Greetings,

 

I'm a new subscriber and apologize if this is a FAQ.  I've read over the
documentation at
http://tomcat.apache.org/tomcat-6.0-doc/config/host.html (under heading
"Automatic Application Deployment") and searched the FAQ at
http://wiki.apache.org/tomcat/FAQ/Deployment.

 

This bullet describes our scenario:

 

*         Updating a WAR file will trigger an undeploy of the
application with the removal of any associated expanded directory,
context file and work directory. Any current user sessions will not be
persisted.

 

We are running Tomcat 6 as bundled with the Amazon AMI image, the RPM
version is tomcat6-6.0.32-1.19.amzn1.noarch.   Java reports version
"1.6.0_20-b20".  Our Host container is declared with autoDeploy enabled:

 

<Host name="localhost"  appBase="webapps"

            unpackWARs="true" autoDeploy="true"

            xmlValidation="false" xmlNamespaceAware="false">

 

We redeployed the app by placing an updated file in the appBase
directory, using "rsync -avz" (preserving file metadata including
timestamps).  We did not restart tomcat at that time.  One day later, we
found that the app did not auto-deploy successfully-the extracted web
app contained a prior version which was still executing.  We resolved it
by forcibly removing the extracted directory and restarting Tomcat.

 

My questions:

 

1.       How precisely does Tomcat 6 determine that a WAR is changed?
By a combination of file size and mtime, or mtime alone?   What is mtime
compared to?

2.       Are there common scenarios in which auto-deploy is known to
fail?   It's hard to find out exactly what happened in our case.  I do
understand the consequences of using "rsync -avz" which has the effect
of manipulating the timestamp on the WAR file, and this timestamp can be
very old.

3.       What are the best practices out there to ensure that "Really
Bad" things cannot happen with webapp deployment?  What do expert users
recommend?  E.g. don't rely on auto-deploy?  Always use Tomcat Manager?
Etc.

 

Thanks in advance for any insight,

 

Jeff