> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Friday, October 08, 2010 3:56 PM > To: Tomcat Users List > Subject: Re: Disable class monitoring for reloading container classes > > -----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
Then according to Jane's description, something is changing the read value of the files' timestamps, as far as Tomcat is concerned. That is the only explanation for what she is seeing. So, Tomcat records the current timestamp for file X as 2010-02-02.11:55:00 on startup. At 2:00am on the first Sunday, the DST kicks in and the next time Tomcat requests file X's timestamp, it gets back the date with conversion applied using the new DST value, so the value is now 1 hour off (+/-), thus the reload. In other words, raw timestamp is not being used, as it should. Could be O/S or Java returning a converted timestamp, or something in how TC is processing the stored time? I seriously doubt this explanation, but it seems the only one to fit. Particularly if Jane is absolutely sure no files are being modified at the time. A timestamp is a timestamp, and should return the same time value for a particular date/time no matter if you are before or after the DST change. (Possible exception for that spring jump when you have repeated times. That is why no changes should be planned for that 2-hour period. The fall one isn't so bad, since an hour just goes missing. God I really hate DST. Don't let me get started on a rant.) __________________________________________________________________________ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
