Christopher Schultz wrote:
...
Technically speaking, the modification date isn't checked against the
context startup date.... it's checked against the last modified date
that was recorded by the ClassLoader. That makes sense because you might
have a JAR file that's been updated but the timestamp is still in the past.
In either case, this seems weird.
Yes, to me too, when compared to what Jane mentioned earlier, and which I
commented :
"
This happens with both DST and standard time changes. What's interesting
is if we go back in time to Oct 29 2006, it does not occur. From March
2007 forward, every fall and spring we get the error when the
application reloads. The DST time change rules changed in March 2007 for
USA time zone.
"
I get this uneasy feeling about this, but I agree with Christopher that it's easy to get
confused, and uneasy to describe.
Let's do this graphically. Below is a timeline. 0 is when Tomcat starts, and
(supposedly) the base reference time for this application.
A "!" symbol marks when Tomcat checks if a file has been modified. A "x" symbol marks
when a file /has/ been modified.
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".
At time t4, the application's files "last modified" time still shows t2.5, and the
application's "last reloaded" time shows t3. Since "reloaded" is after "modified", it's
OK, and no reload is necessary.
At time t4.5, the files are modified again.
At time t5, Tomcat (presumably), notes that the "last modify" time of the files (t4.5) is
now higher/later than the application's "last reloaded" stamp (t3); so it reloads the
application, and marks it as "reloaded at time t5".
Now let's imagine the same thing, but at time t4, the system time is reset to
t2.
The "last reloaded" time of the application remains at t3 (it is in memory somewhere, and
is unaffected by the OS time change).
In the filesystem, the files "last modified" timestamp remains at t2.5 (it is also
unaffected by the time change of the OS).
Tomcat moves on, and at the (new) time t3, it finds that the "last reload" is marked t3
but the files "last modified" stamp is t2.5.
t3 > t2.5, so it should not reload, but that may depend on how exactly the calculation
happens. If the calculation involves the current "system time", then there may be a
sneaky bug there.
Now instead, let's suppose that at time t3, the system time is reset to t1.
Tomcat moves on, and at the new time t2, it finds that the files were modified at time
t2.5 (in the future), but the "last reloaded" stamp of the application is t3 (further in
the future). Since t3 > t2.5, it should not reload. But again, some sneaky bug in the
calculation may..
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 ?
I think so :
Say that the system time is reset at t2.999, to t0.999. At the new t1, Tomcat
checks.
It then finds the "last modified" stamp at t2.5, and the "last reloaded" stamp
at t0.
So it reloads the application, and marks it as "reloaded at t1" ("now", from the OS point
of view).
It is right to reload, because the application has really been modified since it was last
loaded. (But this may just be luck).
But now Tomcat moves on and reaches the new t2. It finds the files "last modified" stamp
at t2.5 (they have not changed), and the "last reloaded" at t1. So it (wrongly) reloads
the application again, and marks it as "reloaded at t2".
And it will do it again at t3, because then the application's files will still have the
t2.5 timestamp, and the "last reloaded" would be t2.
Just a scenario of course.
I have not realy worked out what the effect is, if Tomcat is in a 5 seconds sleep, and the
system time is reset during those 5 seconds.
Neither is there any particular reason why the system time (visualised above by the t0,
t1, t2,..) should be synchronised with when Tomcat checks.
I believe the whole thing hangs onto which source of time Tomcat uses to take the "last
reloaded" time, and the source of time used by the filesystem when a file is modified
(which is always the current OS time, and has nothing to do with Tomcat).
I may have made some fundamental mistake in the above, and have been writing
nonsense.
Or maybe I found a terrible bug in Tomcat, which would otherwise cause the next global
financial crisis (and might have caused the last one).
Selfishly, I would prefer the latter. But either way, it was fun.
And it still does not explain why an application would be reloaded in the absence of any
file update. Damn.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
