tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jane Muse" <>
Subject RE: Disable class monitoring for reloading container classes
Date Fri, 08 Oct 2010 00:11:43 GMT
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.

Thanks much,


-----Original Message-----
From: Pid [] 
Sent: Thursday, October 07, 2010 2:52 PM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes

On 07/10/2010 22:30, Christopher Schultz wrote:
> Jane,
> On 10/6/2010 3:39 PM, Jane Muse wrote:
>> There's a backgroundProcessor method in tomcat that checks whether 
>> container classes need to be reloaded, and checks for session 
>> expirations. Is it possible to disable this method, like you can 
>> disable class reloading for the context with reloadable="false"? I'm 
>> using tomcat 6.0.18 on an IBM i (OS400)  version V6R1. When daylight 
>> savings time hits, our application gets reloaded, and the following 
>> statements are in catalina.out:
>> Mar 14, 2010 3:00:08 AM org.apache.catalina.core.StandardContext 
>> reload
>> INFO: Reloading this Context has started
> Does this happen with every DST change that results in the clock being

> set backward? I haven't looked at the code, but I can't imagine that 
> the BackgroundProcessor keeps the timestamp of the last file scan 
> around for comparison. Instead, I would expect logic similar to this:
> while(true) {
>   sleep
>   find files modified since last context startup
>   if file list is non-empty, reload context }
> If the above logic is the actual implementation, then the only time 
> you'd have a problem is when you've deployed a webapp during the 
> window covered by the DST-clock-setback. For instance, if the clock 
> goes from 02:00 early Sunday morning to 00:00 early Sunday morning, 
> then you should only experience some kind of confusion if you deploy 
> between 00:00 and 02:00 the first time through early on Sunday

+1 actually. Logical.


> I've never observed a DST clock-setback trigger a webapp reload.
> -chris

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message