tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jane Muse" <JM...@aldon.com>
Subject RE: Disable class monitoring for reloading container classes
Date Thu, 07 Oct 2010 01:52:15 GMT
André - you are correct. We actually modified "autoDeploy" attribute on the <Host> element
to false, and not "reloadable" in the application context xml, and then it worked on IBM I
V7R1. Your 3rd point below is probably the key to why it works on one version of the O/S and
not the other. The version where it does not work is Java 1.5.0, and where it does is Java
1.6.0. I have a question into IBM to see if I can change the Java used by the O/S. Do you
know how I could change the JVM used by tomcat on a machine?

re: your fourth point I test this by changing the system time on the O/S.

I couldn't figure out how to test your last guess because the context element in tomcat's
context.xml wouldn't accept the reloadable attribute.

Thanks,

Jane

 

-----Original Message-----
From: André Warnier [mailto:aw@ice-sa.com] 
Sent: Wednesday, October 06, 2010 1:34 PM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes

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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message