https://bz.apache.org/bugzilla/show_bug.cgi?id=57765
Bug ID: 57765
Summary: autodeploy sometimes fails to redeploy the latest war
Product: Tomcat 7
Version: 7.0.56
Hardware: PC
OS: All
Status: NEW
Severity: major
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: alex.henev...@cloudsoftcorp.com
if a war file is updated multiple times within a 1s window the autodeployment
logic may fail to deploy the latest war.
this is particularly a problem if doing something like wget to install a war
directly to the webapps directory. it may fail (because the zip is invalid)
but then not retry when the download completes (presumably because the file
timestamp is not different to the failed timestamp, even though the file *is*
different.)
for example, try the following script:
while [ true ] ; do
curl http://path/to/large/sample.war -o sample.war
sleep 15
if [ ! -d sample ] ; then exit ; fi
done
with the sleep 15, tomcat should be guaranteed to unpack the war (running with
its default 10s detect audodeployment files). however this script usually fails
one in 20 times with a sufficiently large war file (where download time is
>5s). in such cases the last autodeployment attempt logs an invalid zip, there
is no subsequent autodeployment, and the timestamp of the completed (valid)
download is identical to the log timestamp of the failed autodeployment, at
least to a one-second resolution (common on filesystems).
what i suspect is happening is, for example:
00:00:00.100 sample.war is partially written
00:00:00.200 autodeployment is attempted, and fails
00:00:00.300 sample.war is completely written
00:00:10.200 subsequent autodeployment cycle does not attempt re-deployment
i suspect that at time 00:00:00.200, when the deployment fails, it records a
"last update" timestamp. 10 seconds later it checks the timestamp of the file
on disk, which will be 00:00:00 (note no milliseconds) which is not later than
the "last update" timestamp and so it incorrectly skips the redeployment.
this could probably also result in the following situation
00:00:00.100 sample.war v1 is written
00:00:00.200 autodeployment is done
00:00:00.300 sample.war v2 is written
00:00:10.200 subsequent autodeployment cycle does not attempt re-deployment
and so v1 is deployed even though v2 was subsequently written.
i suggest that autodeployment should wait for files to stabilise, i.e. skipping
any file updated within the 1s window immediately prior to autodeployment (and
ensuring that it is picked up on the next autodeployment cycle, unless it is
still being changed).
there are workarounds:
* download to a tmp directory then atomically `mv` the file to the webapps
directory upon completion
* use the manager webapp instead of autodeployment
but it would be nice to fix this so that autodeployment works as advertised
(and i think the fix sketched here should be fairly straightforward).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
