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/webrev_8048020/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.
