tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jane Muse" <JM...@aldon.com>
Subject RE: Disable class monitoring for reloading container classes
Date Fri, 08 Oct 2010 23:40:44 GMT
 
<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:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


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


Mime
View raw message