tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 8645] New: - Microsoft "Services for UNIX v2.0" nfs server has a corrupt last modification date
Date Tue, 30 Apr 2002 09:32:53 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8645>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8645

Microsoft "Services for UNIX v2.0" nfs server has a corrupt last modification date

           Summary: Microsoft "Services for UNIX v2.0" nfs server has a
                    corrupt last modification date
           Product: Tomcat 3
           Version: 3.3.1 Final
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Webapps
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: puckman@taglab.com


This might or might not be Tomcat's problem, however I've found no 
documentation of this problem anywhere on the web, and Tomcat is severly 
affected. If Tomcat is behaving according to plan, then this bug report can be 
seen more as "for information purposes".

Microsoft's "Services for UNIX v2.0" http://www.microsoft.com/windows2000/sfu/ 
includes an NFS server amongst other things. This server has a big problem 
with last modification times of files. 

My setup is a Windows 2000 Server with Services for UNIX, sharing some folders 
using NFS to a Redhat Linux 7.2 box where I'm running tomcat on the NFS file 
system. 

It seems the NFS server sets the modification time twice for every update to 
the file. First when the NFS write is done to memory, and second when the 
change is flushed out to disk. I have verified that the second modification 
date change happens when I see a change in the NTFS file system. 

Consider the following shell excercise where we can see the modification date 
changing twice just using some normal shell tools:

$ pwd 
/home/martin

$ mount | grep /home/martin
winserv:/user_folders/martin on /home/martin type nfs (rw,hard,addr=10.8.0.2)

$ date ; echo "foo" >> bar ; ls --full-time bar
Tue Apr 30 09:42:21 BST 2002
-rw-rw-r--    1 martin   dev             4 Tue Apr 30 09:42:21 2002 bar

$ date ; ls --full-time bar
Tue Apr 30 09:42:31 BST 2002
-rw-rw-r--    1 martin   dev             4 Tue Apr 30 09:42:23 2002 bar


In words what we see is that the file gets a new modification time when I do 
the echo to the file. And roughly ten seconds later when I look at it again. 
The modification time has changed again (after that it stays as is). The 
second change is always around 2 seconds later.

Needless to say this has quite significant impacts on applications like 
Tomcat, where the modificaion time is used to determine reloads. The behaviour 
I'm seeing in Tomcat is along the lines of:

A) .jsp gets compiled to .java that gets compiled to .class
2002-04-30 09:03:12 - Ctx() : Compiling: /index.jsp to index_0

B) A dependency graph is built inside Tomcat using 
org.apache.tomcat.util.Dependecy and org.apache.tomcat.util.DependManager. The 
dependencies seems to be:
ROOT context -> .jsp
ROOT context -> .java 
ROOT context -> .class

C) At a later request the DependManager will validate the dependencies and 
finds the the .class file to have changed. (DependManager contains logging, 
but it is not possible to turn on without editing the class):
DependManager: Found expired file index_1.class
DependManager: ShouldReload5 E=true C=false

D) This triggers an invalidation of the whole dependency graph (my guess) that 
ultimatelly triggers the reload of the context:
2002-04-30 09:05:58 - ContextManager: Removing context 
martin.www.ioboxgroup.com.developer.taglab.com:/ROOT
2002-04-30 09:05:58 - Ctx() : Remove mapping
2002-04-30 09:05:58 - Ctx() : Remove mapping /index.jsp
2002-04-30 09:05:58 - ContextManager: Adding context 127.0.0.1:/ROOT

My webapps doesn't handle this reload very well, so this was a problem for me. 

Possible fixes:

1) Stop using crap Microsoft solutions.

2) Convince Microsoft to fix this problem (why does the phrase "move a 
mountain" spring to mind?)

3) Make the Dependency class tolerant for "minor changes" in the modification 
date. By testing I have concluded that the second update to the modification 
date seems to always be around 2 seconds after the first. The solution I've 
implemented locally allows for a 4 second change without doing a reload. This 
has of course the unwanted side effect that if I update say a JSP two times 
within 4 seconds, the server might not notice the second change. Arguably this 
is a fix for the symptoms and not the cause, and hence is probably nothing we 
would like to see in the Tomcat code base.

4) Should a change in the .class file really trigger a reload of the whole 
context? In the DependManager there is a concept of files being "local" or 
not "local". A change in a local is seemed to not be a reason to invalidate 
the whole Dependency manager. I am not sure I have all the facts about 
the "local" concept, but perhaps the .class file should be considered local, 
and hence not trigger context reloads?

Thanks,
Martin Algesten

Below is a diff of my current fix 3). I don't believe we want this in the code 
base but for reference:

$ diff -u Dependency.java-2002-04-29 Dependency.java
--- Dependency.java-2002-04-29  Mon Apr 29 19:30:17 2002
+++ Dependency.java     Mon Apr 29 19:30:49 2002
@@ -163,7 +163,26 @@
      *  be called to force a check for this particular dependency.
      */
     public boolean checkExpiry() {
-       if( lastModified < origin.lastModified() ) {
+
+        // Fix for broken Microsoft NFS, where the modification date
+        // gets set twice on a modification/creation of a file. First
+        // just after it has been updated and then again after approximatelly
+        // 2 seconds.
+
+        long o = origin.lastModified();
+
+        long t = o - lastModified;
+
+        // if the update was made in less that 4 seconds, then we ignore it
+        // and update our internal timestamp.
+        if ( t < 4000 ) {
+
+          lastModified = o;
+          return false;
+
+        }
+
+       if( lastModified < o ) {
            expired=true;
            return true;
        }

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message