RFR: 8048020 - Regression on java.util.logging.FileHandler (original) (raw)

Daniel Fuchs daniel.fuchs at oracle.com
Wed Jun 25 15:21:03 UTC 2014

On 6/25/14 5:07 PM, Alan Bateman wrote:

On 24/06/2014 19:34, Daniel Fuchs wrote:

Hi,

Please find below a patch [1] for [2]: 8048020 - Regression on java.util.logging.FileHandler This corresponds to the problem that was discussed on this list in the following email thread: "Zombie FileHandler locks can exhaust all available log file locks." http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027296.html

[1] http://cr.openjdk.java.net/~dfuchs/webrev8048020/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8048020 This patch would be a good candidate for being backported on 8, since the issue was introduced in 8. Catching OverlappingFileLockException is usually a sign of a mis-use. Can you summarize how this comes about (given the locking on "locks").

A file is just a file. So nothing prevents some other piece of code in the same process to call FileChannel.lock() directly. For instance, another Handler implementation might do that - given that our 'locks' HashMap is private - it wouldn't be able to use it.

The three Files.isXXX are expensive. This may be a case where you just attempt to create the file with FileChannel.open. It probably should be CREATE + WRITE + APPEND to avoid the case of another process or VM removing the file at around the same time.

The issue here is that CREATE + WRITE + APPEND will probably succeed if the file exists - even though we can't write in its parent dir. I am not sure we should be concerned about the performance of opening the file for the FileHandler. It's usually not something you do very often.

However - Jason is right - there is the potential for a race condition - so I should probably catch FileNotFoundException for the second call to FileChannel.open.

-- daniel

-Alan.

More information about the core-libs-dev mailing list