Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/13/2010 5:41 PM, Jane Muse wrote: We have a directory called COMPANY_NAME/tomcat that is CATALINA_BASE. I sent the contents of CATALINA_BASE/conf/context.xml in the email below. Great. It's probably not necessary to comment-out the WatchedResource as the context should not be reloadable if you set reloadable=true, though I haven't tried actually 'touch'ing web.xml just to see if it would trigger a context reload. We have a CATALINA_BASE/WEBAPPS/APP_NAME directory. Okay. If you have a standard server.xml, that means that APP_NAME will be deployed to /APP_NAME automatically, unless you have Host autoDeploy=false. We also have a COMPANY_NAME/APP_CONF_DIR that contains a /conf directory, the APP_NAME.war file, and an APP_NAME.xml file. Those files will be ignored unless there are other configuration settings that make them relevant. There is a context element defined in the COMPANY_NAME/APP_CONF/DIR/app_name.xml file with reloadable=false. This is the one I was changing. However it turns out that we used this one as a placeholder in case the one in the CATALINA_BASE/conf/[enginename]/[hostname]/app_name.xml got deleted. That sounds like a good plan. Again, the file you were editing was not being consulted by Tomcat. You'll need to copy that file into CATALINA_BASE/conf/[enginename]/[hostname]/[app_name].xml. As Chuck states, you must remove the path attribute from the Context element: it will be ignored at best and cause a double-deployment (or failed deployment) at worst. Or, it might cause your webapp to reload for unknown reasons :) We also have a context element in a place I hadn't seen before at: CATALINA_BASE/conf/[enginename]/[hostname]/app_name.xml. This context element had reloadable=true. I changed it to reloadable=false and restarted tomcat. Now the app does not get reloaded! Fixed. Thanks to all. This was going to be my final attempt: that you were editing the wrong configuration file. Still, we'd love to hear the resolution of the file timestamp changing when DST kicks-in. Please let us know what you find out. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky3GZEACgkQ9CaO5/Lv0PBMWACeL/QV75reOUF3KPewOcdwp7KO jBEAoMGqeakQr/JsiEMpGFGJTwcSl7Nw =5BkZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Disable class monitoring for reloading container classes It's probably not necessary to comment-out the WatchedResource as the context should not be reloadable if you set reloadable=true, Is that a typo? Do you mean reloadable=false? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 10/14/2010 11:18 AM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Disable class monitoring for reloading container classes It's probably not necessary to comment-out the WatchedResource as the context should not be reloadable if you set reloadable=true, Is that a typo? Do you mean reloadable=false? Er, yeah. It's overcast and rainy here today, making my brain move slowly. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky3I+kACgkQ9CaO5/Lv0PAWDwCgtqsEnEqfGmKLrgU68qujXWdx qPQAn04mg3npXZrdkFp80YiexY0Of9eX =ZXrQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
Chris wrote: It's probably not necessary to comment-out the WatchedResource We didn't change WatchedResource in context.xml from how it was installed in tomcat 6.0.18. The default is commented out. But thanks for the info. If you have a standard server.xml, that means that APP_NAME will be deployed to /APP_NAME automatically, unless you have Host autoDeploy=false. And if autoDeploy=false then you have to shutdown tomcat, delete the CATALINA_BASE/WEBAPPS/APP_NAME directory, and restart tomcat in order for the webapp to deploy, correct? I think we'll do it this way in the production environment. you must remove the path attribute from the Context element: Ok, I removed it. It's not necessary because the name of the.xml file will be used as the context path, correct? we'd love to hear the resolution of the file timestamp changing when DST kicks-in I'll definitely let you know! Thanks much, Jane -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, October 14, 2010 7:54 AM To: Tomcat Users List Subject: Re: Disable class monitoring for reloading container classes -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/13/2010 5:41 PM, Jane Muse wrote: We have a directory called COMPANY_NAME/tomcat that is CATALINA_BASE. I sent the contents of CATALINA_BASE/conf/context.xml in the email below. Great. It's probably not necessary to comment-out the WatchedResource as the context should not be reloadable if you set reloadable=true, though I haven't tried actually 'touch'ing web.xml just to see if it would trigger a context reload. We have a CATALINA_BASE/WEBAPPS/APP_NAME directory. Okay. If you have a standard server.xml, that means that APP_NAME will be deployed to /APP_NAME automatically, unless you have Host autoDeploy=false. We also have a COMPANY_NAME/APP_CONF_DIR that contains a /conf directory, the APP_NAME.war file, and an APP_NAME.xml file. Those files will be ignored unless there are other configuration settings that make them relevant. There is a context element defined in the COMPANY_NAME/APP_CONF/DIR/app_name.xml file with reloadable=false. This is the one I was changing. However it turns out that we used this one as a placeholder in case the one in the CATALINA_BASE/conf/[enginename]/[hostname]/app_name.xml got deleted. That sounds like a good plan. Again, the file you were editing was not being consulted by Tomcat. You'll need to copy that file into CATALINA_BASE/conf/[enginename]/[hostname]/[app_name].xml. As Chuck states, you must remove the path attribute from the Context element: it will be ignored at best and cause a double-deployment (or failed deployment) at worst. Or, it might cause your webapp to reload for unknown reasons :) We also have a context element in a place I hadn't seen before at: CATALINA_BASE/conf/[enginename]/[hostname]/app_name.xml. This context element had reloadable=true. I changed it to reloadable=false and restarted tomcat. Now the app does not get reloaded! Fixed. Thanks to all. This was going to be my final attempt: that you were editing the wrong configuration file. Still, we'd love to hear the resolution of the file timestamp changing when DST kicks-in. Please let us know what you find out. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky3GZEACgkQ9CaO5/Lv0PBMWACeL/QV75reOUF3KPewOcdwp7KO jBEAoMGqeakQr/JsiEMpGFGJTwcSl7Nw =5BkZ -END PGP SIGNATURE- - 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
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/14/2010 11:42 AM, Jane Muse wrote: Chris wrote: It's probably not necessary to comment-out the WatchedResource We didn't change WatchedResource in context.xml from how it was installed in tomcat 6.0.18. The default is commented out. But thanks for the info. That's not what Subversion says: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_18/conf/context.xml Someone has modified this file. If you have a standard server.xml, that means that APP_NAME will be deployed to /APP_NAME automatically, unless you have Host autoDeploy=false. And if autoDeploy=false then you have to shutdown tomcat, delete the CATALINA_BASE/WEBAPPS/APP_NAME directory, and restart tomcat in order for the webapp to deploy, correct? I think we'll do it this way in the production environment. If you really are using CATALINA_BASE/conf/[enginename]/[hostname]/[appname].xml, then I wouldn't expect anything to be copied into CATALINA_BASE/webapps during deployment. Instead, the WAR should be exploded into the CATALINA_BASE/work directory. You should definitely delete that if you intend to re-deploy your webapp. When you re-deploy, you should either check CATALINA_BASE/conf/[enginename]/[hostname]/[appname].xml or delete it and update it from your canonical source (COMPANY_NAME/APP_CONF/DIR/app_name.xml or was it COMPANY_NAME/APP_CONF_DIR/conf/APP_NAME.xml or was it COMPANY_NAME/APP_CONF_DIR/APP_NAME.xml... it wasn't at all clear from your previous message). you must remove the path attribute from the Context element: Ok, I removed it. It's not necessary because the name of the.xml file will be used as the context path, correct? It's actually illegal. I wish someone would apply a patch that would refuse to deploy a context with the path specified in it. It's probably too much of a pain to code it so that it knows when it's actually legal (when it's in server.xml, which is not recommended). we'd love to hear the resolution of the file timestamp changing when DST kicks-in I'll definitely let you know! Good luck, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky3KPQACgkQ9CaO5/Lv0PBulACfQJcY6/6ZcGLTOtbytC7JnVbb 77gAnR6UWh3s5eWD02nx7fsxh4MGFZ6v =yJ4S -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
Thanks for the java program Chris, I ran it on the version of the O/S where we
get the problem and got results that show a last modified date that differs by
one hour when the time changes due to DST.
Current GMT time (no DST): 2010-10-12 22:53:27 GMT
Current local time (with DST): 2010-10-12 15:53:28 PDT
File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar]
last modified timestamp: 1231267693000
the file was last modified 55656315 seconds ago
last modified as GMT time (no DST): 2009-01-06 18:48:13 GMT
last modified as local time: 2009-01-06 10:48:13 PST
Change date to: 03/13/10
java com.aldon.lifetime.permissions.test.TimeChange
'/Aldon/Aldonls/tomcat20/lib/servlet-api.jar'
Current GMT time (no DST): 2010-03-13 23:55:24 GMT
Current local time (with DST): 2010-03-13 15:55:24 PST
File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar]
last modified timestamp: 1231271293000
the file was last modified 37253231 seconds ago
last modified as GMT time (no DST): 2009-01-06 19:48:13 GMT
last modified as local time: 2009-01-06 11:48:13 PST
IBM has said they'll open a discussion with their development team and try to
get a fix out.
Thanks to everyone for all the help.
Jane
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, October 12, 2010 11:08 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 10/10/2010 9:09 AM, André Warnier wrote:
What would be really nice, is if someone wrote a quick Java equivalent
to the perl script I submitted.
See below. There's actually more code than absolutely necessary, but it's more
straightforward this way.
Now if you *really* insist, the modified version of the perl program,
below, will explicitly use a couple of C functions, themselves using
the builtin C structures to get the file's last modified time.
Running C in perl, scary stuff..
Are you submitting an application for an obfuscated C program, here?
Sheesh. What's wrong with a little C code?
Amazing: the C code is shorter than the Java code. *shrug*
Time.java (apologies for any re-formatting done by my emailer)
- -
import java.io.File;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.TimeZone;
public class Time
{
public static void main(String[] args)
throws Exception
{
if(args.length 1)
{
System.out.println(Usage: java Time filename);
System.exit(1);
}
// GMT current time
Calendar now = Calendar.getInstance(TimeZone.getTimeZone(GMT));
System.out.println(Current GMT time (no DST):
+ format(now));
// local current time
now = Calendar.getInstance(); // default = local
System.out.println(Current local time (with DST):
+ format(now));
// File timestamp
System.out.println(File [ + args[0] + ]);
File file = new File(args[0]);
long timestamp = file.lastModified();
System.out.println(last modified timestamp: + timestamp);
System.out.println(the file was last modified
+ ((System.currentTimeMillis() - timestamp) /
1000)
+ seconds ago);
Calendar tstamp = Calendar.getInstance(TimeZone.getTimeZone(GMT));
tstamp.setTimeInMillis(file.lastModified());
System.out.println(last modified as GMT time (no DST):
+ format(tstamp));
tstamp = Calendar.getInstance(); // default=local
tstamp.setTimeInMillis(file.lastModified());
System.out.println(last modified as local time:
+ format(tstamp));
}
public static String format(Calendar c)
{
SimpleDateFormat format = new SimpleDateFormat(-MM-dd HH:mm:ss z);
//format.setTimeZone(tz);
format.setTimeZone(c.getTimeZone());
return format.format(c.getTime());
}
}
time.c
- --
#include stdio.h
#include time.h
#include stdlib.h
#include sys/stat.h
int main(int argc, char *argv[]) {
time_t now;
struct tm *gmt;
struct tm *local;
struct stat *fileinfo;
int retval;
char *filename;
if(argc 2) {
printf(missing filename\n);
return 1;
}
filename = argv[1];
gmt = (struct tm*)malloc(sizeof(struct tm));
local = (struct tm*)malloc(sizeof(struct tm));
time(now);
gmtime_r(now, gmt);
localtime_r(now, local);
/* note
RE: Disable class monitoring for reloading container classes
Chris, I found that reloadable=false does not suppress tomcat from watching if files change in WEB-INF/lib, even though the docs say it does: 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. True, there is a bug in the IBM O/S where when DST hits, last modified date for a file gets interpreted as one hour difference. But if reloadable=false was working as it says it should, that would be a way to get around this bug. Can I safely say I've run into both an IBM and a tomcat bug? I'm on tomcat 6.0.18 and I've searched the 6.0.29 change logs, didn't see anything for this issue that's been fixed. Thanks, Jane -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, October 12, 2010 11:16 AM To: Tomcat Users List Subject: Re: Disable class monitoring for reloading container classes -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/9/2010 11:09 AM, Jane Muse wrote: My understanding from the docs is that reloading=false means you can't drop in a war file while tomcat is running and expect it to deploy. No, Context reloadable=false (reloading is meaningless) means that Tomcat will ignore any files within a webapp that have been updated. Host autoDeploy=false means that Tomcat will not look for .war files and automatically deploy them. reloading=false means tomcat is not listening / watching if something changes in WEB-INF/classes or WEB-INF/web.xml, and reload if there's a change. Correct, if s/reloading/reloadable/. If that's what these mean, then we don't need them. Generally speaking, it's best to set both of these to false in production because you don't want anything to happen automatically. We don't have WatchedResource set anywhere either. If anyone knows of a way to suppress tomcat from watching if something in WEB-INF/lib has changed, I think that might work here. Context reloadable=false ought to do the trick. But apparently tomcat is hard wired to reload if it thinks there's a change in that directory. Only if reloadable=true, which is NOT the default. I'm not sure if that would be considered a bug in the O/S, or the JVM, or if tomcat can be made to suppress watching this, similar to what the autoDeploy and reloading settings provide. Let's put it this way, it would be a lot easier to get a change made to tomcat than to IBM's O/S, or Oracle's JVM 8-) Agreed, but it's hard to imagine how this situation would be detectable. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0pcQACgkQ9CaO5/Lv0PAmfwCfRHBsjuVKjBB6mGswfiZ4jHMk TvIAoL/EYf/iIcSsdM0u6eVYs4AwOLfI =mcCD -END PGP SIGNATURE- - 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
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/13/2010 1:40 PM, Jane Muse wrote: Thanks for the java program Chris, I ran it on the version of the O/S where we get the problem and got results that show a last modified date that differs by one hour when the time changes due to DST. Current GMT time (no DST): 2010-10-12 22:53:27 GMT Current local time (with DST): 2010-10-12 15:53:28 PDT File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar] last modified timestamp: 1231267693000 the file was last modified 55656315 seconds ago last modified as GMT time (no DST): 2009-01-06 18:48:13 GMT last modified as local time: 2009-01-06 10:48:13 PST Change date to: 03/13/10 java com.aldon.lifetime.permissions.test.TimeChange '/Aldon/Aldonls/tomcat20/lib/servlet-api.jar' Current GMT time (no DST): 2010-03-13 23:55:24 GMT Current local time (with DST): 2010-03-13 15:55:24 PST File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar] last modified timestamp: 1231271293000 the file was last modified 37253231 seconds ago last modified as GMT time (no DST): 2009-01-06 19:48:13 GMT last modified as local time: 2009-01-06 11:48:13 PST IBM has said they'll open a discussion with their development team and try to get a fix out. Someone had a suggestion about the use of NFS. Are you using a remote filesystem that might be mutating the file timestamps? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky1+KIACgkQ9CaO5/Lv0PA0aQCffNfPI8JGlH9wrzRbzw9rFg9L DCgAnjKwE1Nodu6cj180aKqVfv5pvXBs =ki8t -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/13/2010 1:51 PM, Jane Muse wrote: I found that reloadable=false does not suppress tomcat from watching if files change in WEB-INF/lib, even though the docs say it does: Please log a bug. Note that bugs logged against old versions of Tomcat (6.0.18 is over two years old) are often met with upgrade to latest, then retest instructions. Upgrading would certainly be a good idea in general. Can I safely say I've run into both an IBM and a tomcat bug? I'm not convinced that either are true, honestly. There are plenty of explanations that do not require either your OS or Tomcat to have a bug. I'm on tomcat 6.0.18 and I've searched the 6.0.29 change logs, didn't see anything for this issue that's been fixed. We run in production on 5.5.x and 6.0.x both with default reloadable values (that is, false) and changes to files in WEB-INF/classes and WEB-INF/lib do not trigger automatic reloads. My experience leads me to believe that Tomcat works properly and that your configuration is somehow broken. Can you post your TOMCAT_HOME/conf/context.xml file as well as your webapp's META-INF/context.xml file? Take care to remove sensitive information, particularly from the latter. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky1+a8ACgkQ9CaO5/Lv0PAVswCfaSG12tBF+pILKASF6TKMQatf XvcAoL13iNq5KfXdTljWjAxg6TAl9Hns =k6mc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
Here's my context.xml: Beginning of data** ?xml version='1.0' encoding='utf-8'? !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- The contents of this file will be loaded for each web application -- Context !-- Default set of monitored resources -- !-- WatchedResourceWEB-INF/web.xml/WatchedResource -- !-- Uncomment this to disable session persistence across Tomcat restarts -- !-- Manager pathname= / -- !-- Uncomment this to enable Comet connection tacking (provides events on session expiration as well as webapp lifecycle) -- !-- Valve className=org.apache.catalina.valves.CometConnectionManagerValve / -- /Context _ We are not defining our webapps context file in META-INF/context.xml. It is outside the CATALINA_BASE, in a separate directory that contains the War file, the context file and a conf directory for the webapp. Here's the contents of the webapp.xml file: Beginning of data** Context docBase=webapp_dir/webapp.war path=webapp reloadable=false /Context _ webapp is the name of the webapp directory in catalina_base/webapps/webapp. Jane End of Data -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, October 13, 2010 11:26 AM To: Tomcat Users List Subject: Re: Disable class monitoring for reloading container classes -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/13/2010 1:51 PM, Jane Muse wrote: I found that reloadable=false does not suppress tomcat from watching if files change in WEB-INF/lib, even though the docs say it does: Please log a bug. Note that bugs logged against old versions of Tomcat (6.0.18 is over two years old) are often met with upgrade to latest, then retest instructions. Upgrading would certainly be a good idea in general. Can I safely say I've run into both an IBM and a tomcat bug? I'm not convinced that either are true, honestly. There are plenty of explanations that do not require either your OS or Tomcat to have a bug. I'm on tomcat 6.0.18 and I've searched the 6.0.29 change logs, didn't see anything for this issue that's been fixed. We run in production on 5.5.x and 6.0.x both with default reloadable values (that is, false) and changes to files in WEB-INF/classes and WEB-INF/lib do not trigger automatic reloads. My experience leads me to believe that Tomcat works properly and that your configuration is somehow broken. Can you post your TOMCAT_HOME/conf/context.xml file as well as your webapp's META-INF/context.xml file? Take care to remove sensitive information, particularly from the latter. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky1+a8ACgkQ9CaO5/Lv0PAVswCfaSG12tBF+pILKASF6TKMQatf XvcAoL13iNq5KfXdTljWjAxg6TAl9Hns =k6mc -END PGP SIGNATURE- - 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
RE: Disable class monitoring for reloading container classes
From: Jane Muse [mailto:jm...@aldon.com] Subject: RE: Disable class monitoring for reloading container classes Here's my context.xml: !-- WatchedResourceWEB-INF/web.xml/WatchedResource -- That may not be illegal syntax for XML, but it certainly is confusing. Better to do this: !-- WatchedResourceWEB-INF/web.xml/WatchedResource -- We are not defining our webapps context file in META-INF/context.xml. It is outside the CATALINA_BASE, in a separate directory that contains the War file, the context file and a conf directory for the webapp. See below for your self-contradictory statement. Here's the contents of the webapp.xml file: Which is located where? Beginning of data** Context docBase=webapp_dir/webapp.war path=webapp reloadable=false /Context That's even more confusing and definitely not valid syntax, as well as having an illegal path attribute. webapp is the name of the webapp directory in catalina_base/webapps/webapp. So is your webapp in catalina_base/webapps or not? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
Chuck, Thanks for your persistence! I'll try to explain with examples. We have a directory called COMPANY_NAME/tomcat that is CATALINA_BASE. I sent the contents of CATALINA_BASE/conf/context.xml in the email below. We have a CATALINA_BASE/WEBAPPS/APP_NAME directory. We also have a COMPANY_NAME/APP_CONF_DIR that contains a /conf directory, the APP_NAME.war file, and an APP_NAME.xml file. There is a context element defined in the COMPANY_NAME/APP_CONF/DIR/app_name.xml file with reloadable=false. This is the one I was changing. However it turns out that we used this one as a placeholder in case the one in the CATALINA_BASE/conf/[enginename]/[hostname]/app_name.xml got deleted. We also have a context element in a place I hadn't seen before at: CATALINA_BASE/conf/[enginename]/[hostname]/app_name.xml. This context element had reloadable=true. I changed it to reloadable=false and restarted tomcat. Now the app does not get reloaded! Fixed. Thanks to all. Jane -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Wednesday, October 13, 2010 12:57 PM To: Tomcat Users List Subject: RE: Disable class monitoring for reloading container classes From: Jane Muse [mailto:jm...@aldon.com] Subject: RE: Disable class monitoring for reloading container classes Here's my context.xml: !-- WatchedResourceWEB-INF/web.xml/WatchedResource -- That may not be illegal syntax for XML, but it certainly is confusing. Better to do this: !-- WatchedResourceWEB-INF/web.xml/WatchedResource -- We are not defining our webapps context file in META-INF/context.xml. It is outside the CATALINA_BASE, in a separate directory that contains the War file, the context file and a conf directory for the webapp. See below for your self-contradictory statement. Here's the contents of the webapp.xml file: Which is located where? Beginning of data** Context docBase=webapp_dir/webapp.war path=webapp reloadable=false /Context That's even more confusing and definitely not valid syntax, as well as having an illegal path attribute. webapp is the name of the webapp directory in catalina_base/webapps/webapp. So is your webapp in catalina_base/webapps or not? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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
RE: Disable class monitoring for reloading container classes
That was me in another thread. Here's what I stated: It just occurred to me that I don't think anyone's asked if these are net-mounted file systems. I've seen this timestamp-shifting before, but only on net-mounted filesystems. Usually the source and local systems are set to different timezones (or DST settings). Jeff -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, October 13, 2010 1:21 PM To: Tomcat Users List Subject: Re: Disable class monitoring for reloading container classes -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/13/2010 1:40 PM, Jane Muse wrote: Thanks for the java program Chris, I ran it on the version of the O/S where we get the problem and got results that show a last modified date that differs by one hour when the time changes due to DST. Current GMT time (no DST): 2010-10-12 22:53:27 GMT Current local time (with DST): 2010-10-12 15:53:28 PDT File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar] last modified timestamp: 1231267693000 the file was last modified 55656315 seconds ago last modified as GMT time (no DST): 2009-01-06 18:48:13 GMT last modified as local time: 2009-01-06 10:48:13 PST Change date to: 03/13/10 java com.aldon.lifetime.permissions.test.TimeChange '/Aldon/Aldonls/tomcat20/lib/servlet-api.jar' Current GMT time (no DST): 2010-03-13 23:55:24 GMT Current local time (with DST): 2010-03-13 15:55:24 PST File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar] last modified timestamp: 1231271293000 the file was last modified 37253231 seconds ago last modified as GMT time (no DST): 2009-01-06 19:48:13 GMT last modified as local time: 2009-01-06 11:48:13 PST IBM has said they'll open a discussion with their development team and try to get a fix out. Someone had a suggestion about the use of NFS. Are you using a remote filesystem that might be mutating the file timestamps? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky1+KIACgkQ9CaO5/Lv0PA0aQCffNfPI8JGlH9wrzRbzw9rFg9L DCgAnjKwE1Nodu6cj180aKqVfv5pvXBs =ki8t -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
RE: Disable class monitoring for reloading container classes
The IBM I uses its own integrated file system (IFS). You can access it locally with map network drives, but my tests did not involve doing that. Jane -Original Message- From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Sent: Wednesday, October 13, 2010 3:20 PM To: Tomcat Users List Subject: RE: Disable class monitoring for reloading container classes That was me in another thread. Here's what I stated: It just occurred to me that I don't think anyone's asked if these are net-mounted file systems. I've seen this timestamp-shifting before, but only on net-mounted filesystems. Usually the source and local systems are set to different timezones (or DST settings). Jeff -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, October 13, 2010 1:21 PM To: Tomcat Users List Subject: Re: Disable class monitoring for reloading container classes -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/13/2010 1:40 PM, Jane Muse wrote: Thanks for the java program Chris, I ran it on the version of the O/S where we get the problem and got results that show a last modified date that differs by one hour when the time changes due to DST. Current GMT time (no DST): 2010-10-12 22:53:27 GMT Current local time (with DST): 2010-10-12 15:53:28 PDT File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar] last modified timestamp: 1231267693000 the file was last modified 55656315 seconds ago last modified as GMT time (no DST): 2009-01-06 18:48:13 GMT last modified as local time: 2009-01-06 10:48:13 PST Change date to: 03/13/10 java com.aldon.lifetime.permissions.test.TimeChange '/Aldon/Aldonls/tomcat20/lib/servlet-api.jar' Current GMT time (no DST): 2010-03-13 23:55:24 GMT Current local time (with DST): 2010-03-13 15:55:24 PST File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar] last modified timestamp: 1231271293000 the file was last modified 37253231 seconds ago last modified as GMT time (no DST): 2009-01-06 19:48:13 GMT last modified as local time: 2009-01-06 11:48:13 PST IBM has said they'll open a discussion with their development team and try to get a fix out. Someone had a suggestion about the use of NFS. Are you using a remote filesystem that might be mutating the file timestamps? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky1+KIACgkQ9CaO5/Lv0PA0aQCffNfPI8JGlH9wrzRbzw9rFg9L DCgAnjKwE1Nodu6cj180aKqVfv5pvXBs =ki8t -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 10/10/2010 9:09 AM, André Warnier wrote:
What would be really nice, is if someone wrote a quick Java equivalent
to the perl script I submitted.
See below. There's actually more code than absolutely necessary, but
it's more straightforward this way.
Now if you *really* insist, the modified version of the perl program,
below, will explicitly use a couple of C functions, themselves using the
builtin C structures to get the file's last modified time.
Running C in perl, scary stuff..
Are you submitting an application for an obfuscated C program, here?
Sheesh. What's wrong with a little C code?
Amazing: the C code is shorter than the Java code. *shrug*
Time.java (apologies for any re-formatting done by my emailer)
- -
import java.io.File;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.TimeZone;
public class Time
{
public static void main(String[] args)
throws Exception
{
if(args.length 1)
{
System.out.println(Usage: java Time filename);
System.exit(1);
}
// GMT current time
Calendar now = Calendar.getInstance(TimeZone.getTimeZone(GMT));
System.out.println(Current GMT time (no DST):
+ format(now));
// local current time
now = Calendar.getInstance(); // default = local
System.out.println(Current local time (with DST):
+ format(now));
// File timestamp
System.out.println(File [ + args[0] + ]);
File file = new File(args[0]);
long timestamp = file.lastModified();
System.out.println(last modified timestamp: + timestamp);
System.out.println(the file was last modified
+ ((System.currentTimeMillis() - timestamp) /
1000)
+ seconds ago);
Calendar tstamp = Calendar.getInstance(TimeZone.getTimeZone(GMT));
tstamp.setTimeInMillis(file.lastModified());
System.out.println(last modified as GMT time (no DST):
+ format(tstamp));
tstamp = Calendar.getInstance(); // default=local
tstamp.setTimeInMillis(file.lastModified());
System.out.println(last modified as local time:
+ format(tstamp));
}
public static String format(Calendar c)
{
SimpleDateFormat format = new SimpleDateFormat(-MM-dd
HH:mm:ss z);
//format.setTimeZone(tz);
format.setTimeZone(c.getTimeZone());
return format.format(c.getTime());
}
}
time.c
- --
#include stdio.h
#include time.h
#include stdlib.h
#include sys/stat.h
int main(int argc, char *argv[]) {
time_t now;
struct tm *gmt;
struct tm *local;
struct stat *fileinfo;
int retval;
char *filename;
if(argc 2) {
printf(missing filename\n);
return 1;
}
filename = argv[1];
gmt = (struct tm*)malloc(sizeof(struct tm));
local = (struct tm*)malloc(sizeof(struct tm));
time(now);
gmtime_r(now, gmt);
localtime_r(now, local);
/* note: asctime adds a newline */
printf(System raw timestamp: %ld\n, now);
printf(Current GMT time (no DST): %s, asctime(gmt));
printf(Current local time (with DST): %s, asctime(local));
fileinfo = (struct stat *)malloc(sizeof(struct stat));
printf(File [%s]:\n, filename);
if(stat(filename, fileinfo)) {
perror(filename);
} else {
gmtime_r((fileinfo-st_mtime), gmt);
localtime_r((fileinfo-st_mtime), local);
printf(last modified timestamp: %ld\n, (long)fileinfo-st_mtime);
printf(the file was last modified %ld seconds ago\n,
(now - fileinfo-st_mtime));
printf(last modified as GMT time (no DST): %s, asctime(gmt));
printf(last modified as local time (with DST): %s, asctime(local));
}
return 0;
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAky0o+QACgkQ9CaO5/Lv0PBbvACeLdBAsYKcpP95KkKvJQCNhBP5
TbUAnAxjQk/yLYhSvoq/uWbcl6b6mbv2
=7yhg
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/9/2010 12:02 AM, Jane Muse wrote: Chris wrote: It's too bad the log doesn't show the old timestamp versus the new one. The log shows the timestamp for the file I meant that it would be nice if the log said something like File X had timestamp Y and now has timestamp Z: triggering a context reload. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0pEwACgkQ9CaO5/Lv0PCt/QCgjozaK2LGXSA7fRPg2OV61iEl kEgAn32gUNkwSRC2bNayKXQZR8dNsENZ =b9F0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/9/2010 11:09 AM, Jane Muse wrote: My understanding from the docs is that reloading=false means you can't drop in a war file while tomcat is running and expect it to deploy. No, Context reloadable=false (reloading is meaningless) means that Tomcat will ignore any files within a webapp that have been updated. Host autoDeploy=false means that Tomcat will not look for .war files and automatically deploy them. reloading=false means tomcat is not listening / watching if something changes in WEB-INF/classes or WEB-INF/web.xml, and reload if there's a change. Correct, if s/reloading/reloadable/. If that's what these mean, then we don't need them. Generally speaking, it's best to set both of these to false in production because you don't want anything to happen automatically. We don't have WatchedResource set anywhere either. If anyone knows of a way to suppress tomcat from watching if something in WEB-INF/lib has changed, I think that might work here. Context reloadable=false ought to do the trick. But apparently tomcat is hard wired to reload if it thinks there's a change in that directory. Only if reloadable=true, which is NOT the default. I'm not sure if that would be considered a bug in the O/S, or the JVM, or if tomcat can be made to suppress watching this, similar to what the autoDeploy and reloading settings provide. Let's put it this way, it would be a lot easier to get a change made to tomcat than to IBM's O/S, or Oracle's JVM 8-) Agreed, but it's hard to imagine how this situation would be detectable. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0pcQACgkQ9CaO5/Lv0PAmfwCfRHBsjuVKjBB6mGswfiZ4jHMk TvIAoL/EYf/iIcSsdM0u6eVYs4AwOLfI =mcCD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
This email contained a .zip file attachment. Raytheon does not allow email attachments that are considered likely to contain malicious code. For your protection this attachment has been removed. If this email is from an unknown source, please simply delete this email. If this email was expected, and it is from a known sender, you may follow the below suggested instructions to obtain these types of attachments. + Instruct the sender to enclose the file(s) in a .zip compressed file, and rename the .zip compressed file with a different extension, such as, .rtnzip. Password protecting the renamed .zip compressed file adds an additional layer of protection. When you receive the file, please rename it with the extension .zip. Additional instructions and options on how to receive these attachments can be found at: http://security.it.ray.com/antivirus/extensions.html http://security.it.ray.com/news/2007/zipfiles.html Should you have any questions or difficulty with these instructions, please contact the Help Desk at 877.844.4712 --- Caldarale, Charles R wrote: From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: Disable class monitoring for reloading container classes thanks for the perl program. I would not introduce yet another variable into situation, since perl is not involved in any way with your Tomcat installation, and we don't know how a particular perl implementation might decide to handle timestamps. I recommended C and Java programs since those underly Tomcat, and trying to pinpoint the exact location of the time discrepancy is likely crucial to either fixing it or working around it. Until the actual source of the problem is determined, you're just throwing darts - blindfolded. Charles, I would not dream of disagreeing with you on a Java matter, but in this case, I will. The perl interpreter is usually as close as you can get to the underlying system's libraries without resorting to C, and a perl script is an order of magnitude easier to handle than a C program. What would be really nice, is if someone wrote a quick Java equivalent to the perl script I submitted. Now if you *really* insist, the modified version of the perl program, below, will explicitly use a couple of C functions, themselves using the builtin C structures to get the file's last modified time. Running C in perl, scary stuff.. ;-) The interesting bit however, is when I run this program alternatively on my Windows XP PC and on a Linux server, both set for the same Berlin timezone (GMT+1, current +1h of DST, so GMT+2), I get different answers. For a file in each case modified a few seconds ago, which would be around 12:00 GMT, a) Windows shows : C:\Programs\localperl showmodified.pl showmodified.pl System raw timestamp : 1286712069 Current GMT time (no DST) : 2010/10/10-12:01:09 Current local time (with DST) : 2010/10/10-14:01:09 File [showmodified.pl]: last modified timestamp : 1286712049 the file was last modified 20 seconds ago last modified as GMT time (no DST) : 2010/10/10-12:00:49 last modified as local time (with DST) : 2010/10/10-14:00:49 b) Linux shows : a...@colin:~$ perl showmodified_C.pl showmodified_C.pl System raw timestamp : 1286712131 Current GMT time (no DST) : 2010/10/10-12:02:11 Current local time (with DST) : 2010/10/10-14:02:11 File [showmodified_C.pl]: last modified timestamp : 1286708460 the file was last modified 3671 seconds ago last modified as GMT time (no DST) : 2010/10/10-11:01:00 last modified as GMT time (no DST), as C would have it : 2010/10/10-11:01:00 last modified as local time (with DST) : 2010/10/10-13:01:00 last modified as local time (with DST), as C would have it : 2010/10/10-13:01:00 a...@colin:~$ Even more surprising, for once it seems (to me) that Windows is actually more logical. Or else, the underlying C libraries of Linux somehow adjust the values I'm getting. Windows appears to record (and return) the last modified time of a file as GMT/UTC, while Linux apparently records it as local time, but without the DST adjustment. Or is it recording it as GMT, plus the DST adjustment ? (Unfortunately, the normal timezone here is GMT+1, and the DST adjustment right now is also +1 h, so I do not know which is which.) In any case, I get + one hour difference as compared to Windows, and what I get is nonsense. The file was not modified 3671 seconds ago, it was modified 71 seconds ago. Unfortunately also, changing the system time or its timezone, on the Linux system on which I am testing, is not an option for now. Finding information on the web specifically about different OS'es practices in terms of recording last modified times is apparently not easy. But I did find this rather old discussion of a similar issue, which seems to say the opposite of what I claim above : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4860999 Can anyone smarter than I am throw more light on the subject ? Which, to bring
Re: Disable class monitoring for reloading container classes
Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Disable class monitoring for reloading container classes The timestamp of the file should be /the/ timestamp for the file, and shouldn't be affected by the current DST settings. The timestamp for the file itself might be affected by the current DST setting when you /touch/ it, but not when you do a simple stat() call. My guess is that the problem is specific to the platform: either the JVM or the OS is adjusting the retrieved time stamp, making it relative to the current offset from UTC. Even though this particular OS is not widely used as a Java EE platform (compared to the number of Linux and Windows boxes out there), I'm a bit surprised the issue hasn't been reported elsewhere. Try using simple Java and C programs to check the File.lastModified() and stat() st_mtime values respectively, comparing the results both before and after the DST switch. That should determine if the problem is in the OS, the JVM, or Tomcat. Jane, Below is a simple perl program that will show the last modified time of a file, in 3 flavors : - the original timestamp as a binary value (number of non-leap seconds since the epoch, on most systems this is 00:00:00 UTC, January 1, 1970). - the same timestamp as GMT date/time (this is Greenwich time, non DST-adjusted) - the same time stamp as local time (DST-adjusted) Copy and paste this into a text file, save it as showmodified.pl, then type perl showmodified.pl file_path What would be interesting would be to run the program on your two different servers, to see if they answer differently. This does not use the Java JVM in any way. It uses perl, which itself uses mostly the built-in C library of the OS. So it will tell you what the OS responds for the file timestamps. Someone here might be able to provide a quick Java equivalent, to see if the JVM thinks differently on the same system. Note : I also send the program as an attachment. The list will probably strip it, so I emailed a copy to you directly. #!/usr/bin/perl # showmodified.pl use warnings; use strict; my ($sec,$min,$hour,$mday,$mon,$year); my $subject = $ARGV[0] or die missing argument; die File not found or not readable : $! unless ((-f $subject) (-r $subject)); my $now = time(); ($sec,$min,$hour,$mday,$mon,$year) = gmtime($now); $year +=1900; $mon +=1; print Current GMT time (no DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; ($sec,$min,$hour,$mday,$mon,$year) = localtime($now); $year +=1900; $mon +=1; print Current local time (with DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; print File [$subject]:\n; my ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size, $atime,$mtime,$ctime,$blksize,$blocks) = stat($subject); print last modified timestamp : $mtime\n; print the file was last modified ,$now-$mtime, seconds ago\n; ($sec,$min,$hour,$mday,$mon,$year) = gmtime($mtime); $year +=1900; $mon +=1; print last modified as GMT time (no DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; ($sec,$min,$hour,$mday,$mon,$year) = localtime($mtime); $year +=1900; $mon +=1; print last modified as local time (with DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; exit; #!/usr/bin/perl # showmodified.pl use warnings; use strict; my ($sec,$min,$hour,$mday,$mon,$year); my $subject = $ARGV[0] or die missing argument; die File not found or not readable : $! unless ((-f $subject) (-r $subject)); my $now = time(); ($sec,$min,$hour,$mday,$mon,$year) = gmtime($now); $year +=1900; $mon +=1; print Current GMT time (no DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; ($sec,$min,$hour,$mday,$mon,$year) = localtime($now); $year +=1900; $mon +=1; print Current local time (with DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; print File [$subject]:\n; my ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size, $atime,$mtime,$ctime,$blksize,$blocks) = stat($subject); print last modified timestamp : $mtime\n; print the file was last modified ,$now-$mtime, seconds ago\n; ($sec,$min,$hour,$mday,$mon,$year) = gmtime($mtime); $year +=1900; $mon +=1; print last modified as GMT time (no DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; ($sec,$min,$hour,$mday,$mon,$year) = localtime($mtime); $year +=1900; $mon +=1; print last modified as local time (with DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; exit; - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
I have reloading=false and autoDeploy=false set in the context.xml and server.xml. That's even weirder. How do you deploy Tomcat? Perhaps Tomcat isn't using the server.xml you think it is using. My understanding from the docs is that reloading=false means you can't drop in a war file while tomcat is running and expect it to deploy. reloading=false means tomcat is not listening / watching if something changes in WEB-INF/classes or WEB-INF/web.xml, and reload if there's a change. If that's what these mean, then we don't need them. This is a production environment and we tell our customers to bring down tomcat, delete the app directory under /WEBAPPS, and then drop in a war file if something changes. If they want to do development they should know how to change the properties, etc. If I'm not understanding what autoDeploy and reloading mean, please correct me. I'm now planning to ship the app with these settings, so I hope it works! We don't have WatchedResource set anywhere either. If anyone knows of a way to suppress tomcat from watching if something in WEB-INF/lib has changed, I think that might work here. But apparently tomcat is hard wired to reload if it thinks there's a change in that directory. I'm not sure if that would be considered a bug in the O/S, or the JVM, or if tomcat can be made to suppress watching this, similar to what the autoDeploy and reloading settings provide. Let's put it this way, it would be a lot easier to get a change made to tomcat than to IBM's O/S, or Oracle's JVM 8-) Thanks. Jane -Original Message- From: Jane Muse [mailto:jm...@aldon.com] Sent: Friday, October 08, 2010 9:03 PM To: Tomcat Users List Subject: RE: Disable class monitoring for reloading container classes Chris wrote: It's too bad the log doesn't show the old timestamp versus the new one. The log shows the timestamp for the file Resource '/WEB-INF/lib/ant-1.6.5.jar' was modified; Date is now: Sun Aug 22 19:51:04 PDT 2010 Was: Sun Aug 22 18:51:04 PDT 2010 INFO ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.core.StandardContext - Reloading this Context has started Are you referring to the timestamp of the O/S? The statement right after the one above in the log: Reloading this Context has started only displays when the time changes from 01:59:59 to 03:00 am. See my first email in this thread. Thanks. Jane -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Fri 10/8/2010 6:29 PM To: Tomcat Users List Subject: Re: Disable class monitoring for reloading container classes -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/8/2010 7:40 PM, Jane Muse wrote: Chris wrote: Jane, if you increase your logging level to DEBUG, you should be able to see the modified() method being called, and it should tell you what resource is triggering the reload in the webapp's log file. I set the system date to: 11/07/10 at 1:53:00 and started tomcat. At 2:00 the time changes to 01:00, and the following statements in the log show the resource that was modified: DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - modified() DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - modified() DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - Resource '/WEB-INF/lib/ant-1.6.5.jar' was modified; Date is now: Sun Aug 22 19:51:04 PDT 2010 Was: Sun Aug 22 18:51:04 PDT 2010 INFO ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.core.StandardContext - Reloading this Context has started DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - loadClass(org.apache.struts.action.RequestProcessor, false) When the time fell back 1 hour, the modified time for ant-1.6.5.jar also showed as changed to 1 hour prior to previous timestamp, and that prompted the reload. Thanks for testing this: your experience is very weird. It's too bad the log doesn't show the old timestamp versus the new one. Would you be willing to patch Tomcat to show both timestamps? The timestamp of the file should be /the/ timestamp for the file, and shouldn't be affected by the current DST settings. The timestamp for the file itself might be affected by the current DST setting when you /touch/ it, but not when you do a simple stat() call. I have reloading=false and autoDeploy=false set in the context.xml and server.xml. That's even weirder. How do you deploy Tomcat? Perhaps Tomcat isn't using the server.xml you think it is using. Does this look like a tomcat bug, if so are you aware if it's been fixed in a later version (I'm at 6.0.18)? Wow. That version is 3 years old: it's time to upgrade. :) I couldn't see anything in the changelog (http://tomcat.apache.org/tomcat-6.0-doc
RE: Disable class monitoring for reloading container classes
André, thanks for the perl program. I tried it and got qsh: 001-0019 Error found searching for command showmodified.pl. No such path or directory. when running from the IBM I O/S. I'll talk to IBM next week and see if perl is supported. It might need to be a C program. It ran fine on Linux. If I run the equivalent in C and Java on the two machines and compare the difference, if they're the same then it must be tomcat. I will run them from the command line - before and after the time change. It'll have to be sometime next week. Mean Thanks, Jane -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Saturday, October 09, 2010 7:19 AM To: Tomcat Users List; Jane Muse Subject: Re: Disable class monitoring for reloading container classes Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Disable class monitoring for reloading container classes The timestamp of the file should be /the/ timestamp for the file, and shouldn't be affected by the current DST settings. The timestamp for the file itself might be affected by the current DST setting when you /touch/ it, but not when you do a simple stat() call. My guess is that the problem is specific to the platform: either the JVM or the OS is adjusting the retrieved time stamp, making it relative to the current offset from UTC. Even though this particular OS is not widely used as a Java EE platform (compared to the number of Linux and Windows boxes out there), I'm a bit surprised the issue hasn't been reported elsewhere. Try using simple Java and C programs to check the File.lastModified() and stat() st_mtime values respectively, comparing the results both before and after the DST switch. That should determine if the problem is in the OS, the JVM, or Tomcat. Jane, Below is a simple perl program that will show the last modified time of a file, in 3 flavors : - the original timestamp as a binary value (number of non-leap seconds since the epoch, on most systems this is 00:00:00 UTC, January 1, 1970). - the same timestamp as GMT date/time (this is Greenwich time, non DST-adjusted) - the same time stamp as local time (DST-adjusted) Copy and paste this into a text file, save it as showmodified.pl, then type perl showmodified.pl file_path What would be interesting would be to run the program on your two different servers, to see if they answer differently. This does not use the Java JVM in any way. It uses perl, which itself uses mostly the built-in C library of the OS. So it will tell you what the OS responds for the file timestamps. Someone here might be able to provide a quick Java equivalent, to see if the JVM thinks differently on the same system. Note : I also send the program as an attachment. The list will probably strip it, so I emailed a copy to you directly. #!/usr/bin/perl # showmodified.pl use warnings; use strict; my ($sec,$min,$hour,$mday,$mon,$year); my $subject = $ARGV[0] or die missing argument; die File not found or not readable : $! unless ((-f $subject) (-r $subject)); my $now = time(); ($sec,$min,$hour,$mday,$mon,$year) = gmtime($now); $year +=1900; $mon +=1; print Current GMT time (no DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; ($sec,$min,$hour,$mday,$mon,$year) = localtime($now); $year +=1900; $mon +=1; print Current local time (with DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; print File [$subject]:\n; my ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size, $atime,$mtime,$ctime,$blksize,$blocks) = stat($subject); print last modified timestamp : $mtime\n; print the file was last modified ,$now-$mtime, seconds ago\n; ($sec,$min,$hour,$mday,$mon,$year) = gmtime($mtime); $year +=1900; $mon +=1; print last modified as GMT time (no DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; ($sec,$min,$hour,$mday,$mon,$year) = localtime($mtime); $year +=1900; $mon +=1; print last modified as local time (with DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; exit; - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
Jane Muse wrote: André, thanks for the perl program. I tried it and got qsh: 001-0019 Error found searching for command showmodified.pl. No such path or directory. You may need to adjust the first line of the program, to point to the executable perl interpreter. Use which perl to find this out (well, if these OS'es are anything like Unix-like, that is) when running from the IBM I O/S. I'll talk to IBM next week and see if perl is supported. I would be surprised if it wasn't. It might need to be a C program. It ran fine on Linux. And it should on just about any platform. That's a nice part of perl ... and in principle Java. If I run the equivalent in ((C OR perl) AND Java) on the two machines and compare the difference, if they're the same then it must be tomcat. I'm not sure that I understand your turn of phrase entirely, but yes, that's the idea. C or perl would show you what the OS says about a file's timestamp. Java will show you what the JVM says about the same timestamp. If the two answers differ, then it is definitely the JVM. It would be even clearer then if you could compare different JVMs on the same machine. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: Disable class monitoring for reloading container classes thanks for the perl program. I would not introduce yet another variable into situation, since perl is not involved in any way with your Tomcat installation, and we don't know how a particular perl implementation might decide to handle timestamps. I recommended C and Java programs since those underly Tomcat, and trying to pinpoint the exact location of the time discrepancy is likely crucial to either fixing it or working around it. Until the actual source of the problem is determined, you're just throwing darts - blindfolded. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
On 08/10/2010 01:11, Jane Muse wrote: 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. Random thought. Have the necessary timezone updates been applied to the OS and to Java? If they are out of sync that could make time appear to jump to the JVM. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
On 08/10/2010 01:19, Jane Muse wrote: If I changed the system time zone not to change with daylight savings time, then it would be off by an hour. I don't think our customers would like that. Or am I misunderstanding your comment? The system timezone is almost irrelevant, you could use UTC or any other stable timezone setting. The primitive long value of time inside a Date is the same regardless of timezone. It sounds like you're relying on the system time for date display, rather than formatting it as needed when you need to output it. p Thanks, Jane -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Thursday, October 07, 2010 8:23 AM To: Tomcat Users List Subject: Re: Disable class monitoring for reloading container classes On 06/10/2010 20:39, 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: How about fixing the system time zone to be one that doesn't change with daylight time savings? p 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Disable class monitoring for reloading container classes
Jane Muse wrote: If I changed the system time zone not to change with daylight savings time, then it would be off by an hour. I don't think our customers would like that. Or am I misunderstanding your comment? Maybe Pid's comment was partly tongue-in-cheek. You did not misunderstand, but of course it all depends on what your application does, and on whether the system's time difference is visible to them or not. On this : 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. Somehow this suggest to me that there is something else going on. I have not re-done Christopher's reasoning in detail - and Pid seemed to agree, so I'm not going to - and I have also not gone to look at the actual code, but superficially it does not look to me as if a simple time change would trigger any application reload. It would have to be the combined effect of a change to a file's last modified stamp /and/ a system time change, no ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 10/8/2010 4:44 AM, Mark Thomas wrote: On 08/10/2010 01:11, Jane Muse wrote: 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. Random thought. Have the necessary timezone updates been applied to the OS and to Java? If they are out of sync that could make time appear to jump to the JVM. +1 on the hunch, thought I'm still not sure why Tomcat would perform a knee-jerk reload unless the initial deployment occurred during the indeterminate interval between the clock adjustment end points (boy, this is awkward to discuss). We had a problem a few years ago in production where Java hadn't been updated with the new DST rules but the OS had. We try to use NOW() in our database queries as much as possible, but sometimes it makes much more sense to just generate a new java.util.Date object for timestamps and then use those in our SQL queries as well. Due to that incident, we ended up with records in our database that appeared to have been updated before they had been created. Oops. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyvKY0ACgkQ9CaO5/Lv0PB5YgCgouMB1Ip2MfM9/eQb+IsNYJ8X sLcAoK0GzwrD4HKeXP3Vk+pgNKTNHciq =9eZd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, On 10/8/2010 4:44 AM, Pid wrote: On 08/10/2010 01:19, Jane Muse wrote: If I changed the system time zone not to change with daylight savings time, then it would be off by an hour. I don't think our customers would like that. Or am I misunderstanding your comment? The system timezone is almost irrelevant, you could use UTC or any other stable timezone setting. +1 The primitive long value of time inside a Date is the same regardless of timezone. It sounds like you're relying on the system time for date display, rather than formatting it as needed when you need to output it. Yeah, all Date objects ought to be merged with the user's TimeZone to display the proper locale date/time. Unfortunately, a java.util.Date object does /not/ carry TimeZone information with it, but is does depend upon the TimeZone in which it was created. For example, if your system time zone is America/New_York (mine), then all your date objects created during DST are essentially set to (-4 * 60 * 1000) for the timezone offset and (-1 * 60 * 1000) for the DST offset. If you want to convert that into a different time zone, you have to compute the difference between the two time zones. This is one of the reasons it's so advantageous to use UTC for storing dates as well as your system time zone, since the calculations are much simpler because one of the zone/DST offsets is always zero. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyvKxwACgkQ9CaO5/Lv0PDzdQCeI2MjoUV0achEE4mD4cgNbLmH BFUAoIFJKVuSBkA0jWRp5Zl9e9wV8uzl =Mx7U -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, On 10/7/2010 5:52 PM, Pid wrote: On 07/10/2010 22:30, Christopher Schultz wrote: 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 morning. +1 actually. Logical. I browsed the code and it looks like the reload-check is done in the WebappClassLoader.modified() method which you can find in here for Jane's specific version: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_18/java/org/apache/catalina/loader/WebappClassLoader.java Technically speaking, the modification date isn't checked against the context startup date it's checked against the last modified date that was recorded by the ClassLoader. That makes sense because you might have a JAR file that's been updated but the timestamp is still in the past. In either case, this seems weird. Jane, if you increase your logging level to DEBUG, you should be able to see the modified() method being called, and it should tell you what resource is triggering the reload in the webapp's log file. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyvM54ACgkQ9CaO5/Lv0PA6rACfUghfrik2nmW9n7usJZhUMKbZ W9UAnA82HPzCB8rcJTsi8hpou7kzeu/Z =kvUe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
Christopher Schultz wrote: ... Technically speaking, the modification date isn't checked against the context startup date it's checked against the last modified date that was recorded by the ClassLoader. That makes sense because you might have a JAR file that's been updated but the timestamp is still in the past. In either case, this seems weird. Yes, to me too, when compared to what Jane mentioned earlier, and which I commented : 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. I get this uneasy feeling about this, but I agree with Christopher that it's easy to get confused, and uneasy to describe. Let's do this graphically. Below is a timeline. 0 is when Tomcat starts, and (supposedly) the base reference time for this application. A ! symbol marks when Tomcat checks if a file has been modified. A x symbol marks when a file /has/ been modified. 0 1 2 3 4 5 !--!--!x-!--!x-! ... (you get the idea) At time t1, nothing has changed, and nothing happens. At time t2, nothing has changed, and nothing happens. At time t2.5, the application's files are modified. At time t3, Tomcat (presumably), notes that the last modify time of the files (t2.5) is now later than the application's last reloaded stamp (t0); so it reloads the application, and marks it as reloaded at time t3. At time t4, the application's files last modified time still shows t2.5, and the application's last reloaded time shows t3. Since reloaded is after modified, it's OK, and no reload is necessary. At time t4.5, the files are modified again. At time t5, Tomcat (presumably), notes that the last modify time of the files (t4.5) is now higher/later than the application's last reloaded stamp (t3); so it reloads the application, and marks it as reloaded at time t5. Now let's imagine the same thing, but at time t4, the system time is reset to t2. The last reloaded time of the application remains at t3 (it is in memory somewhere, and is unaffected by the OS time change). In the filesystem, the files last modified timestamp remains at t2.5 (it is also unaffected by the time change of the OS). Tomcat moves on, and at the (new) time t3, it finds that the last reload is marked t3 but the files last modified stamp is t2.5. t3 t2.5, so it should not reload, but that may depend on how exactly the calculation happens. If the calculation involves the current system time, then there may be a sneaky bug there. Now instead, let's suppose that at time t3, the system time is reset to t1. Tomcat moves on, and at the new time t2, it finds that the files were modified at time t2.5 (in the future), but the last reloaded stamp of the application is t3 (further in the future). Since t3 t2.5, it should not reload. But again, some sneaky bug in the calculation may.. But can we get a case where the last modified timestamp of the files would /falsely/ be higher than the last reloaded time of the application ? I think so : Say that the system time is reset at t2.999, to t0.999. At the new t1, Tomcat checks. It then finds the last modified stamp at t2.5, and the last reloaded stamp at t0. So it reloads the application, and marks it as reloaded at t1 (now, from the OS point of view). It is right to reload, because the application has really been modified since it was last loaded. (But this may just be luck). But now Tomcat moves on and reaches the new t2. It finds the files last modified stamp at t2.5 (they have not changed), and the last reloaded at t1. So it (wrongly) reloads the application again, and marks it as reloaded at t2. And it will do it again at t3, because then the application's files will still have the t2.5 timestamp, and the last reloaded would be t2. Just a scenario of course. I have not realy worked out what the effect is, if Tomcat is in a 5 seconds sleep, and the system time is reset during those 5 seconds. Neither is there any particular reason why the system time (visualised above by the t0, t1, t2,..) should be synchronised with when Tomcat checks. I believe the whole thing hangs onto which source of time Tomcat uses to take the last reloaded time, and the source of time used by the filesystem when a file is modified (which is always the current OS time, and has nothing to do with Tomcat). I may have made some fundamental mistake in the above, and have been writing nonsense. Or maybe I found a terrible bug in Tomcat, which would otherwise cause the next global financial crisis (and might have caused the last one). Selfishly, I would prefer the latter. But either way, it was fun. And it still does not explain why an application would be reloaded in the absence
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 10/8/2010 2:12 PM, André Warnier wrote: 0 1 2 3 4 5 !--!--!x-!--!x-! ... (you get the idea) At time t1, nothing has changed, and nothing happens. At time t2, nothing has changed, and nothing happens. At time t2.5, the application's files are modified. At time t3, Tomcat (presumably), notes that the last modify time of the files (t2.5) is now later than the application's last reloaded stamp (t0); so it reloads the application, and marks it as reloaded at time t3. Technically speaking, all the files' timestamps are recorded at t0 and compared at tX to their t0 timestamps. When the application is re-loaded, presumably everything is re-scanned and you basically have a new t0 situation. Now let's imagine the same thing, but at time t4, the system time is reset to t2. Here's where my above comment comes into play: the current time has /no bearing on anything/, since the file timestamps are always compared to their previous values. Tomcat doesn't care about when the webapp was last loaded: it only cares about the previously-recorded file timestamp for each file. When tX != t0, a reload is triggered. If I read the code correctly, this means that even if the webapp is intentionally initialized during a clock-setback, it shouldn't reload when the clock actually gets set back. But can we get a case where the last modified timestamp of the files would /falsely/ be higher than the last reloaded time of the application ? Since Tomcat simply does a != check rather than or , I think that none of this should ever happen. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyvhXcACgkQ9CaO5/Lv0PCwNwCfQf9aQJeiXUM2W4LgQj3Rvn/0 kogAoLFnXuNe8gUWBzzDYWB79A55mkBf =+cEv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 10/8/2010 2:12 PM, André Warnier wrote: 0 1 2 3 4 5 !--!--!x-!--!x-! ... (you get the idea) At time t1, nothing has changed, and nothing happens. At time t2, nothing has changed, and nothing happens. At time t2.5, the application's files are modified. At time t3, Tomcat (presumably), notes that the last modify time of the files (t2.5) is now later than the application's last reloaded stamp (t0); so it reloads the application, and marks it as reloaded at time t3. Technically speaking, all the files' timestamps are recorded at t0 and compared at tX to their t0 timestamps. When the application is re-loaded, presumably everything is re-scanned and you basically have a new t0 situation. Now let's imagine the same thing, but at time t4, the system time is reset to t2. Here's where my above comment comes into play: the current time has /no bearing on anything/, since the file timestamps are always compared to their previous values. Tomcat doesn't care about when the webapp was last loaded: it only cares about the previously-recorded file timestamp for each file. When tX != t0, a reload is triggered. If I read the code correctly, this means that even if the webapp is intentionally initialized during a clock-setback, it shouldn't reload when the clock actually gets set back. But can we get a case where the last modified timestamp of the files would /falsely/ be higher than the last reloaded time of the application ? Since Tomcat simply does a != check rather than or , I think that none of this should ever happen. Thanks for checking the code. In that case, - Jane's experience is still incomprehensible - the possible bug I mentioned cannot happen - but the logic used by Tomcat seems wasteful : aren't these a lot of files for which Tomcat needs to keep a timestamp ? But maybe it was done that way /precisely/ to avoid the issue I mentioned. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, October 08, 2010 3:56 PM To: Tomcat Users List Subject: Re: Disable class monitoring for reloading container classes -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 10/8/2010 2:12 PM, André Warnier wrote: 0 1 2 3 4 5 !--!--!x-!--!x-! ... (you get the idea) At time t1, nothing has changed, and nothing happens. At time t2, nothing has changed, and nothing happens. At time t2.5, the application's files are modified. At time t3, Tomcat (presumably), notes that the last modify time of the files (t2.5) is now later than the application's last reloaded stamp (t0); so it reloads the application, and marks it as reloaded at time t3. Technically speaking, all the files' timestamps are recorded at t0 and compared at tX to their t0 timestamps. When the application is re-loaded, presumably everything is re-scanned and you basically have a new t0 situation. Now let's imagine the same thing, but at time t4, the system time is reset to t2. Here's where my above comment comes into play: the current time has /no bearing on anything/, since the file timestamps are always compared to their previous values. Tomcat doesn't care about when the webapp was last loaded: it only cares about the previously-recorded file timestamp for each file. When tX != t0, a reload is triggered. If I read the code correctly, this means that even if the webapp is intentionally initialized during a clock-setback, it shouldn't reload when the clock actually gets set back. But can we get a case where the last modified timestamp of the files would /falsely/ be higher than the last reloaded time of the application ? Since Tomcat simply does a != check rather than or , I think that none of this should ever happen. - -chris Then according to Jane's description, something is changing the read value of the files' timestamps, as far as Tomcat is concerned. That is the only explanation for what she is seeing. So, Tomcat records the current timestamp for file X as 2010-02-02.11:55:00 on startup. At 2:00am on the first Sunday, the DST kicks in and the next time Tomcat requests file X's timestamp, it gets back the date with conversion applied using the new DST value, so the value is now 1 hour off (+/-), thus the reload. In other words, raw timestamp is not being used, as it should. Could be O/S or Java returning a converted timestamp, or something in how TC is processing the stored time? I seriously doubt this explanation, but it seems the only one to fit. Particularly if Jane is absolutely sure no files are being modified at the time. A timestamp is a timestamp, and should return the same time value for a particular date/time no matter if you are before or after the DST change. (Possible exception for that spring jump when you have repeated times. That is why no changes should be planned for that 2-hour period. The fall one isn't so bad, since an hour just goes missing. God I really hate DST. Don't let me get started on a rant.) __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
RE: Disable class monitoring for reloading container classes
Chris wrote: Jane, if you increase your logging level to DEBUG, you should be able to see the modified() method being called, and it should tell you what resource is triggering the reload in the webapp's log file. I set the system date to: 11/07/10 at 1:53:00 and started tomcat. At 2:00 the time changes to 01:00, and the following statements in the log show the resource that was modified: DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - modified() DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - modified() DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - Resource '/WEB-INF/lib/ant-1.6.5.jar' was modified; Date is now: Sun Aug 22 19:51:04 PDT 2010 Was: Sun Aug 22 18:51:04 PDT 2010 INFO ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.core.StandardContext - Reloading this Context has started DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - loadClass(org.apache.struts.action.RequestProcessor, false) When the time fell back 1 hour, the modified time for ant-1.6.5.jar also showed as changed to 1 hour prior to previous timestamp, and that prompted the reload. I have reloading=false and autoDeploy=false set in the context.xml and server.xml. Does this look like a tomcat bug, if so are you aware if it's been fixed in a later version (I'm at 6.0.18)? Many thanks, Jane -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, October 08, 2010 8:07 AM To: Tomcat Users List Subject: Re: Disable class monitoring for reloading container classes -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, On 10/7/2010 5:52 PM, Pid wrote: On 07/10/2010 22:30, Christopher Schultz wrote: 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 morning. +1 actually. Logical. I browsed the code and it looks like the reload-check is done in the WebappClassLoader.modified() method which you can find in here for Jane's specific version: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_18/java/o rg/apache/catalina/loader/WebappClassLoader.java Technically speaking, the modification date isn't checked against the context startup date it's checked against the last modified date that was recorded by the ClassLoader. That makes sense because you might have a JAR file that's been updated but the timestamp is still in the past. In either case, this seems weird. Jane, if you increase your logging level to DEBUG, you should be able to see the modified() method being called, and it should tell you what resource is triggering the reload in the webapp's log file. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyvM54ACgkQ9CaO5/Lv0PA6rACfUghfrik2nmW9n7usJZhUMKbZ W9UAnA82HPzCB8rcJTsi8hpou7kzeu/Z =kvUe -END PGP SIGNATURE- - 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
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 10/8/2010 5:20 PM, André Warnier wrote: In that case, - Jane's experience is still incomprehensible - the possible bug I mentioned cannot happen +1 +1 - but the logic used by Tomcat seems wasteful : aren't these a lot of files for which Tomcat needs to keep a timestamp ? Did you mean aren't /there/ a lot of files...? Yes, there are a lot of files to keep track of, but it really depends on the webapp. It will store the timestamps for all .jar files in the WEB-INF/lib directory, any .class file in WEB-INF/classes, plus anything you've added under a WatchedResource. But maybe it was done that way /precisely/ to avoid the issue I mentioned. Maybe just a happy accident :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyvwS0ACgkQ9CaO5/Lv0PAkQwCffLzQ4zpeWKnKNqCNCvEqpvmn vkAAoJnw4wMGjYVCu1u/BWGxDjB9lfEW =/DlI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/8/2010 7:40 PM, Jane Muse wrote: Chris wrote: Jane, if you increase your logging level to DEBUG, you should be able to see the modified() method being called, and it should tell you what resource is triggering the reload in the webapp's log file. I set the system date to: 11/07/10 at 1:53:00 and started tomcat. At 2:00 the time changes to 01:00, and the following statements in the log show the resource that was modified: DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - modified() DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - modified() DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - Resource '/WEB-INF/lib/ant-1.6.5.jar' was modified; Date is now: Sun Aug 22 19:51:04 PDT 2010 Was: Sun Aug 22 18:51:04 PDT 2010 INFO ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.core.StandardContext - Reloading this Context has started DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - loadClass(org.apache.struts.action.RequestProcessor, false) When the time fell back 1 hour, the modified time for ant-1.6.5.jar also showed as changed to 1 hour prior to previous timestamp, and that prompted the reload. Thanks for testing this: your experience is very weird. It's too bad the log doesn't show the old timestamp versus the new one. Would you be willing to patch Tomcat to show both timestamps? The timestamp of the file should be /the/ timestamp for the file, and shouldn't be affected by the current DST settings. The timestamp for the file itself might be affected by the current DST setting when you /touch/ it, but not when you do a simple stat() call. I have reloading=false and autoDeploy=false set in the context.xml and server.xml. That's even weirder. How do you deploy Tomcat? Perhaps Tomcat isn't using the server.xml you think it is using. Does this look like a tomcat bug, if so are you aware if it's been fixed in a later version (I'm at 6.0.18)? Wow. That version is 3 years old: it's time to upgrade. :) I couldn't see anything in the changelog (http://tomcat.apache.org/tomcat-6.0-doc/changelog.html) that seems likely, but I didn't read it in detail; that's a lot of versions to read through. You might want to read it yourself to see if anything seems applicable, but also to determine if there are any changes that would prohibit you from upgrading. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyvxXEACgkQ9CaO5/Lv0PCtFgCfWU7ffkBC6KWQFWB4CWm6o5mK tisAoLf5eLxFrKkaR8QKezxjfPtTllcF =SlGt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Disable class monitoring for reloading container classes The timestamp of the file should be /the/ timestamp for the file, and shouldn't be affected by the current DST settings. The timestamp for the file itself might be affected by the current DST setting when you /touch/ it, but not when you do a simple stat() call. My guess is that the problem is specific to the platform: either the JVM or the OS is adjusting the retrieved time stamp, making it relative to the current offset from UTC. Even though this particular OS is not widely used as a Java EE platform (compared to the number of Linux and Windows boxes out there), I'm a bit surprised the issue hasn't been reported elsewhere. Try using simple Java and C programs to check the File.lastModified() and stat() st_mtime values respectively, comparing the results both before and after the DST switch. That should determine if the problem is in the OS, the JVM, or Tomcat. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
RE: Disable class monitoring for reloading container classes
Chris wrote: It's too bad the log doesn't show the old timestamp versus the new one. The log shows the timestamp for the file Resource '/WEB-INF/lib/ant-1.6.5.jar' was modified; Date is now: Sun Aug 22 19:51:04 PDT 2010 Was: Sun Aug 22 18:51:04 PDT 2010 INFO ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.core.StandardContext - Reloading this Context has started Are you referring to the timestamp of the O/S? The statement right after the one above in the log: Reloading this Context has started only displays when the time changes from 01:59:59 to 03:00 am. See my first email in this thread. Thanks. Jane -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Fri 10/8/2010 6:29 PM To: Tomcat Users List Subject: Re: Disable class monitoring for reloading container classes -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane, On 10/8/2010 7:40 PM, Jane Muse wrote: Chris wrote: Jane, if you increase your logging level to DEBUG, you should be able to see the modified() method being called, and it should tell you what resource is triggering the reload in the webapp's log file. I set the system date to: 11/07/10 at 1:53:00 and started tomcat. At 2:00 the time changes to 01:00, and the following statements in the log show the resource that was modified: DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - modified() DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - modified() DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - Resource '/WEB-INF/lib/ant-1.6.5.jar' was modified; Date is now: Sun Aug 22 19:51:04 PDT 2010 Was: Sun Aug 22 18:51:04 PDT 2010 INFO ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.core.StandardContext - Reloading this Context has started DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.loader.WebappClassLoader - loadClass(org.apache.struts.action.RequestProcessor, false) When the time fell back 1 hour, the modified time for ant-1.6.5.jar also showed as changed to 1 hour prior to previous timestamp, and that prompted the reload. Thanks for testing this: your experience is very weird. It's too bad the log doesn't show the old timestamp versus the new one. Would you be willing to patch Tomcat to show both timestamps? The timestamp of the file should be /the/ timestamp for the file, and shouldn't be affected by the current DST settings. The timestamp for the file itself might be affected by the current DST setting when you /touch/ it, but not when you do a simple stat() call. I have reloading=false and autoDeploy=false set in the context.xml and server.xml. That's even weirder. How do you deploy Tomcat? Perhaps Tomcat isn't using the server.xml you think it is using. Does this look like a tomcat bug, if so are you aware if it's been fixed in a later version (I'm at 6.0.18)? Wow. That version is 3 years old: it's time to upgrade. :) I couldn't see anything in the changelog (http://tomcat.apache.org/tomcat-6.0-doc/changelog.html) that seems likely, but I didn't read it in detail; that's a lot of versions to read through. You might want to read it yourself to see if anything seems applicable, but also to determine if there are any changes that would prohibit you from upgrading. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyvxXEACgkQ9CaO5/Lv0PCtFgCfWU7ffkBC6KWQFWB4CWm6o5mK tisAoLf5eLxFrKkaR8QKezxjfPtTllcF =SlGt -END PGP SIGNATURE- - 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
Re: Disable class monitoring for reloading container classes
Jane Muse wrote: 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. I believe that if you phrased the question like that, they may not understand what you mean, as the OS itself probably does not use Java. Do you know how I could change the JVM used by tomcat on a machine? To change the JVM used by Tomcat is easy, but first you need to install a 1.6 JVM on that machine. You should be able to install the JVM 1.6 in addition to the existing 1.5, if you have any concern about the possibility of breaking other applications. For the exact way to do that, you will need help from an OS specialist for that machine. Once you have installed this 1.6 JVM, having Tomcat use it instead of the 1.5 JVM is easy. Basically, it consists of setting the environment value JAVA_HOME to point to the new JVM before starting Tomcat. That's all there is to it. That needs to be done somewhere in the scripts which are used at Tomcat start, but I cannot tell you where exactly on that platform. If Java and Tomcat are IBM packages on that platform, then you will probably also need an OS specialist to help you with that. re: your fourth point I test this by changing the system time on the O/S. Right. But my point was : since in reality, on a productive system, this is happening only twice a year, does it matter if those times the application(s) get reloaded ? (In fact, I strongly suspect that it may happen only /at most/ once a year, and then only in very specific circumstances. It is your changing of the system time which triggers the reloading, but it would probably never happen in reality on a production system). 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. That was only a wild unsubstantiated guess. I expect someone else more qualified to shoot down that suggestion, just about... now. Thanks, Welcome. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
On 06/10/2010 20:39, 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: How about fixing the system time zone to be one that doesn't change with daylight time savings? p 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 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: Disable class monitoring for reloading container classes
There are several Java's on the IBM machine. Yesterday I performed tests by changing JAVA_HOME in the catalina startup script to Sun's Java 1.5 and Sun's java 1.6. Previously it was IBM's J9 1.5.0. The results were the same with the various JVM's. The reason why there's a problem when the application gets reloaded is due to we are loading a JNI native library that the application requires. According to the following link, section 11.2.4, the JVM does not allow a JNI native library to be loaded by more than one class loader. When the application is shut down by tomcat, the native library does not get unloaded from the class loader. This only happens when the JVM is brought down. Thus when the application starts up after tomcat reloads it, we get an UnsatisfiedLinkError. http://java.sun.com/docs/books/jni/html/design.html Thanks. -Jane -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Thursday, October 07, 2010 3:26 AM To: Tomcat Users List Subject: Re: Disable class monitoring for reloading container classes Jane Muse wrote: 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. I believe that if you phrased the question like that, they may not understand what you mean, as the OS itself probably does not use Java. Do you know how I could change the JVM used by tomcat on a machine? To change the JVM used by Tomcat is easy, but first you need to install a 1.6 JVM on that machine. You should be able to install the JVM 1.6 in addition to the existing 1.5, if you have any concern about the possibility of breaking other applications. For the exact way to do that, you will need help from an OS specialist for that machine. Once you have installed this 1.6 JVM, having Tomcat use it instead of the 1.5 JVM is easy. Basically, it consists of setting the environment value JAVA_HOME to point to the new JVM before starting Tomcat. That's all there is to it. That needs to be done somewhere in the scripts which are used at Tomcat start, but I cannot tell you where exactly on that platform. If Java and Tomcat are IBM packages on that platform, then you will probably also need an OS specialist to help you with that. re: your fourth point I test this by changing the system time on the O/S. Right. But my point was : since in reality, on a productive system, this is happening only twice a year, does it matter if those times the application(s) get reloaded ? (In fact, I strongly suspect that it may happen only /at most/ once a year, and then only in very specific circumstances. It is your changing of the system time which triggers the reloading, but it would probably never happen in reality on a production system). 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. That was only a wild unsubstantiated guess. I expect someone else more qualified to shoot down that suggestion, just about... now. Thanks, Welcome. - 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
Re: Disable class monitoring for reloading container classes
Jane Muse wrote: .. The reason why there's a problem when the application gets reloaded is due to we are loading a JNI native library that the application requires. According to the following link, section 11.2.4, the JVM does not allow a JNI native library to be loaded by more than one class loader. When the application is shut down by tomcat, the native library does not get unloaded from the class loader. This only happens when the JVM is brought down. Thus when the application starts up after tomcat reloads it, we get an UnsatisfiedLinkError. Ok, I can really not comment on that one. It seems a valid reason to me, but I am by no means a specialist here. There are several Java's on the IBM machine. Yesterday I performed tests by changing JAVA_HOME in the catalina startup script to Sun's Java 1.5 and Sun's java 1.6. Previously it was IBM's J9 1.5.0. The results were the same with the various JVM's. Are you sure that wherever you changed it, is really being used ? If you go to the bin directory of your Tomcat installation, and execute the ./version.sh script, what does it tell you ? The reason I am asking, is that when Tomcat comes pre-packaged for some given OS, the packagers may have provided their own startup scripts, which may not use the standard Tomcat startup scripts, or which may overwrite the JAVA_HOME environment value before actually launching Tomcat. We on this list generally do not know the exact contents of these packages, so you really have to make sure, by following the chain of what happens when you start Tomcat on that machine. If you know where the line is which actually launches Tomcat, you could insert an instruction just before, such as echo Java Home : $JAVA_HOME just to make sure. And there is always the workaround mentioned by Pid.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 morning.
I've never observed a DST clock-setback trigger a webapp reload.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyuPAsACgkQ9CaO5/Lv0PA3bwCgnauu9wy7dILRiDW+5NVAABHa
dPoAn0C+3Z5Ff0roq3CEQbtXS0sj0hqs
=8WJQ
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Disable class monitoring for reloading container classes
On 07/10/2010 21:34, André Warnier wrote: Jane Muse wrote: .. The reason why there's a problem when the application gets reloaded is due to we are loading a JNI native library that the application requires. According to the following link, section 11.2.4, the JVM does not allow a JNI native library to be loaded by more than one class loader. When the application is shut down by tomcat, the native library does not get unloaded from the class loader. This only happens when the JVM is brought down. Thus when the application starts up after tomcat reloads it, we get an UnsatisfiedLinkError. Ok, I can really not comment on that one. It seems a valid reason to me, but I am by no means a specialist here. Sounds like a memory leak in your application, to me. More recent versions of Tomcat have memory leak detection features, you shouldn't have a problem testing with the latest version, even if you can't deploy with it. Monitor the log file(s) for additional information during app restarts. p There are several Java's on the IBM machine. Yesterday I performed tests by changing JAVA_HOME in the catalina startup script to Sun's Java 1.5 and Sun's java 1.6. Previously it was IBM's J9 1.5.0. The results were the same with the various JVM's. Are you sure that wherever you changed it, is really being used ? If you go to the bin directory of your Tomcat installation, and execute the ./version.sh script, what does it tell you ? The reason I am asking, is that when Tomcat comes pre-packaged for some given OS, the packagers may have provided their own startup scripts, which may not use the standard Tomcat startup scripts, or which may overwrite the JAVA_HOME environment value before actually launching Tomcat. We on this list generally do not know the exact contents of these packages, so you really have to make sure, by following the chain of what happens when you start Tomcat on that machine. If you know where the line is which actually launches Tomcat, you could insert an instruction just before, such as echo Java Home : $JAVA_HOME just to make sure. And there is always the workaround mentioned by Pid.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
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 morning.
+1 actually. Logical.
p
I've never observed a DST clock-setback trigger a webapp reload.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
0x62590808.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
RE: Disable class monitoring for reloading container classes
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,
Jane
-Original Message-
From: Pid [mailto:p...@pidster.com]
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
morning.
+1 actually. Logical.
p
I've never observed a DST clock-setback trigger a webapp reload.
-chris
-
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
RE: Disable class monitoring for reloading container classes
If I changed the system time zone not to change with daylight savings time, then it would be off by an hour. I don't think our customers would like that. Or am I misunderstanding your comment? Thanks, Jane -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Thursday, October 07, 2010 8:23 AM To: Tomcat Users List Subject: Re: Disable class monitoring for reloading container classes On 06/10/2010 20:39, 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: How about fixing the system time zone to be one that doesn't change with daylight time savings? p 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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
RE: Disable class monitoring for reloading container classes
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
