RFR: 8048020 - Regression on java.util.logging.FileHandler
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:
>> Please find below a patch  for :
>> 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://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.00/
>>  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.
More information about the core-libs-dev