Zombie FileHandler locks can exhaust all available log file locks. (original) (raw)

Daniel Fuchs 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 CREATENEW + DELETEONCLOSE, 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 CREATENEW.

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 DELETEONCLOSE 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.

More information about the core-libs-dev mailing list