JDK-8031438 : FileHandler throws OverlappingFileLockException
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 7u45
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_7
  • Submitted: 2013-12-24
  • Updated: 2016-01-11
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
The FileHandler documentation doesn't declare that OverlappingFileLockException can be thrown from the constructor. Reading the FileChannel.tryLock documentation it appears that failure to acquire a lock can be indicated by returning null or throwing an OverlappingFileLockException. The FileHandler.openFiles method doesn't seem to handle the case of OverlappingFileLockException being thrown since it extends IllegalStateException.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Use a network file system.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Add a catch block to FileHandler openFiles for OverlappingFileLockException and set available to false.
ACTUAL -
Undocumented OverlappingFileLockException being thrown from constructor.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
OverlappingFileLockException

REPRODUCIBILITY :
This bug can be reproduced rarely.

---------- BEGIN SOURCE ----------
See "OverlappingFileLockException while logging" at

http://stackoverflow.com/questions/20631880/overlappingfilelockexception-while-logging
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Catch the exception and try a different file pattern.
Comments
I have written a test that can reproduce the issue and reproduced it on 1.7_45.
25-06-2014

It would be useful if the submitter could say whether they can duplicate this with JDK 8 or not. I suspect not because of the changes in JDK-6244047 where lock file is generated via the FileChannel.open with the CREATE_NEW option. That should ensure that the lock file name is unique and so there won't be attempts to lock a file that is already locked by the VM (which is why OverlappingFileLockException is thrown).
09-01-2014