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