RFR: 8048020 - Regression on java.util.logging.FileHandler

[Daniel Fuchs]

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.