-
Bug
-
Resolution: Fixed
-
P4
-
8, 9
-
b01
-
generic
-
generic
-
Verified
FULL PRODUCT VERSION :
A DESCRIPTION OF THE PROBLEM :
When a FileLock obtained from a FileChannel gets GC'd (garbage collect'd) the underlying file lock is released. This behavior is very surprising. Since a developer normally wouldn't expect the need to maintain a reference to the obtained FileLock object himself/herself and may easily assume the reference is maintained automatically in the FileChannel object.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the code attached. See code-level documentation for more detail.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Throw an OverlappingFileLockException.
ACTUAL -
File lock released unexpectedly. No OverlappingFileLockException thrown.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.io.File;
import java.io.RandomAccessFile;
public class FileLockBug {
/**
* This class demonstrates a bug in which a FileLock object gets GC'd
* and results in unexpected release of the file lock.
*/
public static void main(String[] args) throws Exception {
final File f = new File("/tmp/file");
final RandomAccessFile raf1 = new RandomAccessFile(f, "rw");
// acquire an exclusive lock
// the returned FileLock has no reference to it
// (candidate for GC)
raf1.getChannel().tryLock();
// force GC and remove the FileLock object created above
System.gc();
final RandomAccessFile raf2 = new RandomAccessFile(f, "rw");
// expected: an OverlappingFileLockException
// (since a lock has already been acquired on the same file)
// actual: lock acquired successfully due to this bug
raf2.getChannel().tryLock();
raf2.close();
raf1.close();
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Always maintain a reference of the FileLock obtained to avoid it being GC'd.
For example:
FileLock fileLock = randomAccessFile.getChannel().tryLock();
...as opposed to
randomAccessFile.getChannel().tryLock();
A DESCRIPTION OF THE PROBLEM :
When a FileLock obtained from a FileChannel gets GC'd (garbage collect'd) the underlying file lock is released. This behavior is very surprising. Since a developer normally wouldn't expect the need to maintain a reference to the obtained FileLock object himself/herself and may easily assume the reference is maintained automatically in the FileChannel object.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the code attached. See code-level documentation for more detail.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Throw an OverlappingFileLockException.
ACTUAL -
File lock released unexpectedly. No OverlappingFileLockException thrown.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.io.File;
import java.io.RandomAccessFile;
public class FileLockBug {
/**
* This class demonstrates a bug in which a FileLock object gets GC'd
* and results in unexpected release of the file lock.
*/
public static void main(String[] args) throws Exception {
final File f = new File("/tmp/file");
final RandomAccessFile raf1 = new RandomAccessFile(f, "rw");
// acquire an exclusive lock
// the returned FileLock has no reference to it
// (candidate for GC)
raf1.getChannel().tryLock();
// force GC and remove the FileLock object created above
System.gc();
final RandomAccessFile raf2 = new RandomAccessFile(f, "rw");
// expected: an OverlappingFileLockException
// (since a lock has already been acquired on the same file)
// actual: lock acquired successfully due to this bug
raf2.getChannel().tryLock();
raf2.close();
raf1.close();
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Always maintain a reference of the FileLock obtained to avoid it being GC'd.
For example:
FileLock fileLock = randomAccessFile.getChannel().tryLock();
...as opposed to
randomAccessFile.getChannel().tryLock();