tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Disable class monitoring for reloading container classes
Date Wed, 06 Oct 2010 20:33:31 GMT
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
> We have been able to stop the application from reloading on a different
> version of the IBM i, version V7R1, by using reloadable="false". However
> on the V6R1 O/S the application still reloads because the background
> processor detects a timestamp change when DST occurs.
>>>From the documentation, it doesn't look like backgroundProcessorDelay
> can be used to suppress backgroundProcess, just to delay it as its name
> implies. 
> We would gladly upgrade tomcat to a more recent version if we thought
> this issue had been resolved, but I don't see any mention of it in the
> change logs.
> - Jane

Hi. I don't really know the answer to your questions, but I will hazard a couple of 
guesses based on the documentation, and on your above description.

First, if I go by the description in the documentation, for the "reloadable" attribute of

the Context element :

"Set to true if you want Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib

for changes, and automatically reload the web application if a change is detected. This 
feature is very useful during application development, but it requires significant runtime

overhead and is not recommended for use on deployed production applications. That's why 
the default setting for this attribute is false. You can use the Manager web application,

however, to trigger reloads of deployed applications on demand."

It thus seems that the default value of this attribute /is/ false.  So your setting it to

false explicitly should not change anything.  Or, the documentation is wrong..

Second, are you sure that you should not be using the "autoDeploy" (="false") attribute of

the <Host> element instead ?  According to its description, this seems more closely

related to the kind of issue you mention.

Third, according to your message above, you seem to be using the same Tomcat version on 
two systems, but they have a different OS.  Presumably, whatever it is in Tomcat which 
checks if it is time to reload an application must be comparing timestamps, uses the same

call to the JVM for ditto, and the JVM (if it is the same), probably uses the same call to

the underlying OS.
So the different behaviour seems to be JVM or OS-linked, not Tomcat-linked.
Do you have any idea why these two OS'es or JVM's return a different reponse to Tomcat for

the same call ? (Maybe the difference in OS is just incidental, and it is really a 
difference in the setup of these systems which makes the difference; or maybe it is the 
JVM which is the cause. Are they the same ?).

Fourth, you are talking about a change resulting from a DST adjustment.  Isn't this 
something which happens at most twice a year ?  Even if it does reload an application 
then, is this really a problem ? (I'll admit again that I don't know, and I'm just curious).
And also, supposing that you get an answer here, does that mean that you will have to wait

6 months to see if it works ?

And last (but here I'm really really guessing), the INFO message you mentioned seems to 
talk about a "StandardContext".  Maybe this is the one which is described by the 
"context.xml" file in the main Tomcat configuration directory (or at least as a default 
for all contexts).  So, supposing that this attribute really has an impact, have you tried

to add the reloadable="false" there ? (no guarantee that this will not have other 
consequences however).

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

View raw message