Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
