https://issues.apache.org/bugzilla/show_bug.cgi?id=48009
Summary: Editing context.xml may cause unwanted undeploy of a
webapp
Product: Tomcat 6
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: peter.crowt...@melandra.com
Tomcat polls context.xml files for changes. If a previously-existing
context.xml is missing at the instant Tomcat polls, then the application is
undeployed.
Some text editors (notably vi and its derivatives) create backup files by: 1)
Renaming the original file, then 2) creating a new file and writing the edited
contents to that file.
Therefore there is a race condition. There is a small but non-zero probability
that a user editing and saving context.xml using such an editor will see their
webapp undeployed. Messages on tomcat-users indicate that such a situation has
occurred on a production server at least once. It's undoubtedly rare.
Suggested fixes:
- Examine the directory for the presence of backup files for context.xml, and
do not undeploy if one is found even if context.xml is missing. This is
horribly ugly and makes the semantics of "a backup file" very peculiar, but is
actually the only way to *prevent* the race - anything else only makes it less
likely, as on a heavily loaded system (or one where context.xml is being edited
via a network file share) the interval between the old context.xml being
renamed and the new one being created may be arbitrarily long.
- Only undeploy if the file is missing for a period of time. The discussion is
then around that period. On tomcat-users, Mark Thomas suggested polling again
after 500ms; I suggested remembering the state between polls and only
undeploying if the file was missing for two successive polls. This is a
cleaner fix to explain, but is not a complete solution as it does not remove
the possibility of such a race.
---
As an aside, there may well be a similar issue where Tomcat polls for
context.xml as it is being written, finds it has changed, and reads a
part-written version. In mitigation, the files involved are typically small
and may well be written in one or very few operations; however, Tomcat should
probably not assume that any file change is atomic.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- 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
