tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Disable class monitoring for reloading container classes
Date Fri, 08 Oct 2010 21:20:14 GMT
Christopher Schultz wrote:
> Hash: SHA1
> André,
> On 10/8/2010 2:12 PM, André Warnier wrote:
>> 0          1          2          3          4          5
>> !----------!----------!----x-----!----------!----x-----! ... (you get
>> the idea)
>> At time t1, nothing has changed, and nothing happens.
>> At time t2, nothing has changed, and nothing happens.
>> At time t2.5, the application's files are modified.
>> At time t3, Tomcat (presumably), notes that the "last modify" time of
>> the files (t2.5) is now later than the application's "last reloaded"
>> stamp (t0); so it reloads the application, and marks it as "reloaded at
>> time t3".
> Technically speaking, all the files' timestamps are recorded at t0 and
> compared at tX to their t0 timestamps. When the application is
> re-loaded, presumably everything is re-scanned and you basically have a
> new t0 situation.
>> Now let's imagine the same thing, but at time t4, the system time is
>> reset to t2.
> Here's where my above comment comes into play: the current time has /no
> bearing on anything/, since the file timestamps are always compared to
> their previous values. Tomcat doesn't care about when the webapp was
> last loaded: it only cares about the previously-recorded file timestamp
> for each file. When tX != t0, a reload is triggered.
> If I read the code correctly, this means that even if the webapp is
> intentionally initialized during a clock-setback, it shouldn't reload
> when the clock actually gets set back.
>> But can we get a case where the "last modified" timestamp of the files
>> would /falsely/ be higher than the "last reloaded" time of the
>> application ?
> Since Tomcat simply does a != check rather than < or >, I think that
> none of this should ever happen.

Thanks for checking the code.

In that case,
- Jane's experience is still incomprehensible
- the possible bug I mentioned cannot happen
- but the logic used by Tomcat seems wasteful : aren't these a lot of files for which 
Tomcat needs to keep a timestamp ?
But maybe it was done that way /precisely/ to avoid the issue I mentioned.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message