1

It appears that java 8 made a change to how lock files are treated and it is causing me to accumulate a lot of .lck files.

I thought to solve this by adding some code to my app to clean up lock files in my output directory every time it runs. Java however does not hold this file open, meaning if I open a second instance of my app (common use case) then this will cause it to delete the lock file and promptly hang when trying to re-use the same log files as the other instance.

Has anyone mitigated this in a more graceful manner?

Confirmed this is a bug in at least 8u25. Bad behavior goes away in the oracle 8u40 JRE.

Sparkfizt
  • 113
  • 1
  • 8
  • There is no such "file type" as lock files. `.lck` is but a file extension, that is all. Which OS is that? How is it related to logging? – fge Feb 24 '15 at 23:27
  • Do you actually mean a `log file`? – Zhedar Feb 24 '15 at 23:41
  • 2
    .lck files are used by the java logging api to show that log files are currently in use by a java process (on windows at least) – Sparkfizt Feb 25 '15 at 03:32

1 Answers1

2

This is covered in Is java.util.logging.FileHandler in Java 8 broken?. Update your JDK 8 to update 40 or newer which contains the fix for JDK-8048020.

You should expect to see lock files when the FileHandler is open. If you see them linger after the VM exits, then it is because the The FileHandler was not closed, the VM was halted or crashed while the handler shutdown hook was running, or an I/O exception took place while trying to remove them.

The platform you are running on also plays a role when it comes to the implementation of FileLock used by the FileHandler. The FileLock documentation comes with the following warning:

Whether or not a lock actually prevents another program from accessing the content of the locked region is system-dependent and therefore unspecified. The native file-locking facilities of some systems are merely advisory, meaning that programs must cooperatively observe a known locking protocol in order to guarantee data integrity. On other systems native file locks are mandatory, meaning that if one program locks a region of a file then other programs are actually prevented from accessing that region in a way that would violate the lock. On yet other systems, whether native file locks are advisory or mandatory is configurable on a per-file basis. To ensure consistent and correct behavior across platforms, it is strongly recommended that the locks provided by this API be used as if they were advisory locks.

That means the FileHandler can have different locking behavior on different platforms.

Also related to lock files is garbage collection of loggers which won't close the attached handlers. These issues are covered under JDK-8060132: Handlers configured on abstract nodes in logging.properties are not always properly closed and JDK-6274920: JDK logger holds strong reference to java.util.logging.Logger instances.

Community
  • 1
  • 1
jmehrens
  • 10,580
  • 1
  • 38
  • 47
  • That link suggests the lock incrementing behavior is a change from 7 to 8. I'm not having issues with lock files expiring on a clean shutdown. I'll test on u45 on Thursday to see if its any different. – Sparkfizt Feb 25 '15 at 03:34
  • "You should expect to see lock files when the FileHandler is open. If you see them linger after the VM exits, then it is because the The FileHandler was not closed, the VM was halted or crashed while the handler shutdown hook was running, or an I/O exception took place while trying to remove them." Correct, this is the behavior I expect and see. Previously in java 7 those lock files would get re-used because the VM would check to see if the files were being held open. Now it will never re-use a lock file, the presence of a lock causes it to increment to the next. – Sparkfizt Feb 27 '15 at 15:57
  • This is observed on the oracle JRE 8u25. – Sparkfizt Feb 27 '15 at 15:57
  • Sorry for all the replies, upon further testing it appears there may be (unsurprisingly) something on my end. – Sparkfizt Feb 27 '15 at 16:13