tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jane Muse" <>
Subject RE: Disable class monitoring for reloading container classes
Date Sat, 09 Oct 2010 16:31:28 GMT
thanks for the perl program. I tried it and got 

   qsh: 001-0019 Error found searching for command 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 


-----Original Message-----
From: André Warnier [] 
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 []
>> 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
> 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.


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 "", then type

perl <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.

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) : 

($sec,$min,$hour,$mday,$mon,$year) = localtime($now);
$year +=1900; $mon +=1;
print "Current local time (with DST) : 

print "File [$subject]:\n";

my ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,
            = 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) : 

($sec,$min,$hour,$mday,$mon,$year) = localtime($mtime);
$year +=1900; $mon +=1;
print "last modified as local time (with DST) : 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message