Name: nt126004			Date: 02/08/2002


FULL PRODUCT VERSION :
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)

FULL OPERATING SYSTEM VERSION :
Linux 2.4.4-4GB
Suse 7.2 + security upgrades
KDE 2 wm



EXTRA RELEVANT SYSTEM CONFIGURATION :
Home directory imported over nfs.

A DESCRIPTION OF THE PROBLEM :
java.util.prefs code throws exception very some time and
when exiting an application. This in fact happens when prefs
code tries to save preferences - and locking lock file fails
(because home directory and thus .java subdir is imported
over net).
This is already hinted at bugs #4463603 and #4481237 and
marked 'closed and solved'. But it is NOT. I'm resubmitting
this bug, because it is rc1 now and it is quite critical for
usage of 1.4 - it is absolutely not acceptable for our
clients to see stack trace with errors every minute or so
(no, redirecting to /dev/null won't do the trick).

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Run ANY java application
2. Close it
3. Observe standard output

EXPECTED VERSUS ACTUAL BEHAVIOR :
I think that file should be actually locked and data
written. Now it just throws exception.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.SecurityException: Could not lockUser prefs.Lock file access denied.
        at
java.util.prefs.FileSystemPreferences.checkLockFile0ErrorCode(FileSystemPreferences.java:874)
        at
java.util.prefs.FileSystemPreferences.lockFile(FileSystemPreferences.java:863)
        at
java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:665)
        at
java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:756)
        at
java.util.prefs.FileSystemPreferences.syncWorld(FileSystemPreferences.java:423)
        at
java.util.prefs.FileSystemPreferences.access$1200(FileSystemPreferences.java:33)
        at
java.util.prefs.FileSystemPreferences$9.run(FileSystemPreferences.java:416)

This bug can be reproduced always.

-------BEGIN SOURCE-------------
import java.util.prefs.*;

public class Test
{
   public static void main(String[] argv)
   {
     Preferences.userRoot();
   }
}
--------END SOURCE--------------

CUSTOMER WORKAROUND :
Somehow make sure that ~/.java is not on nfs. I've done it
by softlinking it to /tmp which is on local filesystem.
(Review ID: 138659) 
======================================================================


###@###.### 2002-03-22

Same problem reported by the CAP member with the consequences that 
are  far worse than just some exception output. 

J2SE Version (please include all output from java -version flag):
  J2SDK1.4.0fcs

Does this problem occur on J2SE 1.3?  Yes / No (pick one)
  No.

Operating System Configuration Information (be specific):
  Different flavors of Linux. $HOME/.java/ accessed via NFS.

Bug Description:
  There are several reports of a serious problem which involves the file
  locking mechanism of java.util.prefs.FilesystemPreferences on Linux.

  If the user runs a Java program for an hour or longer eventually the program
  will not be able to do any I/O via NFS AT ALL anymore and get the following
  error messages:

   Dec 4, 2001 7:20:08 PM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode 
   WARNING: Could not lock User prefs. Unix error code 5. 
   Dec 4, 2001 7:20:08 PM java.util.prefs.FileSystemPreferences syncWorld 
   WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock. 
   Dec 4, 2001 7:20:38 PM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode 
   WARNING: Could not lock User prefs. Unix error code 5. 
   Dec 4, 2001 7:20:38 PM java.util.prefs.FileSystemPreferences syncWorld 
   WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock. 


  Suspect that this problem arises due to some resource exhaustion (file
  descriptors?) in the native function which is responsible for file locking 
  in java.util.prefs.FilesystemPreferences:

  The UNIX java.util.prefs.FilesystemPreferences implementations syncs
  preference values to disk every 30 seconds. This is why this message appears
  in 30-second intervals. Before it syncs those values to disk it acquires a
  filesystem lock to avoid having to Java applications syncing values to disk 
  at once. This locking operation is performed even if there is nothing to 
  sync to disk.
                   
  The locking operation fails with UNIX error code 5 (EIO) in above case which
  suggests that an I/O error occured while creating the lockfile. The lockfile
  (and the preferences) are located in the ".java" directory in the home directory. 
  So it seems that after a while the running Java application cannot write 
  into the home directory anymore. 
  
  The problem vanishes if the user moves .java to /tmp/ and creates a symlink
  back into his homedirectory.

  Please audit the FilesystemPreferences native locking code to check if
  there is something obviously wrong.