Zombie FileHandler locks can exhaust all available log file locks.

[Daniel Fuchs]

On 6/23/14 4:53 PM, Alan Bateman wrote:
> On 23/06/2014 10:48, Daniel Fuchs wrote:
>> :
>>
>> All in all - I feel our best options would be to revert to using
>> CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
>> and live with the issue.
>> Hopefully some nio experts will chime in ;-)
>>
> The logging use of FileLock is a bit unusual but looking at it now then
> I don't see the reason why it needs to use CREATE_NEW.

OK - thanks - in the discussion that ended up in the patch where
CREATE_NEW was introduced Jason (I think it was Jason) pointed at
https://bugs.openjdk.java.net/browse/JDK-4420020

I'm guessing here that maybe it would be wrong to use an already
existing lock file if you don't have the rights to write to
its directory - and that using CREATE_NEW ensures that you have
all necessary access rights all along the path.

> I don't think
> DELETE_ON_CLOSE is suitable here as that work is for transient work
> files which isn't the case here. Instead it could use deleteOnExit to
> have some chance of removing it on a graceful exit.

Right - I suggested a patch in another mail where I just use that.

>
> BTW: Do you know why locks is Map? Would a Set do?

It certainly looks as if we could use a simple HashSet here.

Thanks Alan!

-- daniel

>
> -Alan.
>