Bug 48009 - Editing context.xml may cause unwanted undeploy of a webapp
Editing context.xml may cause unwanted undeploy of a webapp
Product: Tomcat 6
Classification: Unclassified
Component: Catalina
All All
: P2 normal (vote)
: default
Assigned To: Tomcat Developers Mailing List
Depends on:
  Show dependency tree
Reported: 2009-10-16 01:52 UTC by Peter Crowther
Modified: 2009-11-02 15:26 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Crowther 2009-10-16 01:52:21 UTC
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.
Comment 1 Mark Thomas 2009-10-21 13:55:47 UTC
This has been fixed in trunk and proposed for 6.0.x.

I went for the simple if file is deleted, wait 500ms and check it is still deleted. It isn't perfect but no solution can be,
Comment 2 Mark Thomas 2009-11-02 15:26:36 UTC
Fixed in 6.0.x and will be in 6.0.21 onwards.