Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4CAF5F0D.10100@ice-sa.com>
Date: Fri, 08 Oct 2010 20:12:29 +0200
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Disable class monitoring for reloading container classes
References: <BAE7FA6DEC47CE41B484D09EBDDA3AEA0476B1D2@gluon.hq.aldon.com>
 <4CAE3C0B.2060901@christopherschultz.net> <4CAE4113.5000209@pidster.com>
 <4CAF339F.5070806@christopherschultz.net>
In-Reply-To: <4CAF339F.5070806@christopherschultz.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org