-----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.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyvhXcACgkQ9CaO5/Lv0PCwNwCfQf9aQJeiXUM2W4LgQj3Rvn/0
kogAoLFnXuNe8gUWBzzDYWB79A55mkBf
=+cEv
-----END PGP SIGNATURE-----

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

Reply via email to