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