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
