tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: 6.0.20 - New behavior on conf/Catalina/<host>/<ctxpath>.xml update. Why redeploy?
Date Thu, 01 Oct 2009 13:53:46 GMT
Peter Crowther wrote:
> 2009/10/1 Mark Thomas <markt@apache.org>:
>> Peter Crowther wrote:
>>> I wonder whether this is a race condition with some text editors.  For
>>> example, if vi operated in the following way:
>>> 1) Rename context.xml to context.xml~
>>> 2) Create context.xml, write contents, close file
>>> ... then a poll of the state of context.xml between 1 and 2 would show
>>> context.xml as missing.
>>>
>>> A swift perusal of the vim/gvim sources indicates that at least those
>>> two editors operate in exactly this way.  There's a small period when
>>> the file would appear not to be present if polled.
>> That could explain what Igor saw although the odds of it happening must
>> be pretty small. Could you raise a bug for this in Bugzilla? For the fix
>> I'm thinking along the lines of waiting 500ms if the file appears to be
>> deleted to check that it doesn't re-appear before continuing.
> 
> The odds would increase on a heavily loaded system, but I agree it's
> pretty unlikely.
> 
> On the flip side, most people would only notice it if, like Igor, they
> didn't have the war file and had autoDeploy set to "true".  In any
> other situation this would cause a re-deploy rather than a re-load,
> but the system would recover to its previous state.  So it might be
> more common than we know!

The WAR file would be deleted as well.

> I'll create a Bugzilla entry once Bugzilla responds - at present it's
> timing out on 3 page loads in 4.

Thanks. There has been a DDOS against the server that runs Bugzilla for the last
few days. infra is doing what it can to mitigate the effects.

>  My own suggested fix would have been
> to delete only if two successive polls indicated that the file had
> been deleted, but you know the source code far better than I do.

I was going for the easy option :) - depending on the the detail of the current
implementation, your approach could be just as simple - I'll take a look.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message