Zombie FileHandler locks can exhaust all available log file locks.
daniel.fuchs at oracle.com
Mon Jun 23 15:13:04 UTC 2014
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
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.
More information about the core-libs-dev