Daniel,
Looks bullet proof to me. Jason ---------------------------------------- > Date: Tue, 1 Jul 2014 11:25:33 +0200 > From: daniel.fu...@oracle.com > To: jason_mehr...@hotmail.com; core-libs-dev@openjdk.java.net > CC: alan.bate...@oracle.com > Subject: Re: RFR: 8048020 - Regression on java.util.logging.FileHandler > > On 6/25/14 2:34 PM, Jason Mehrens wrote: >> Daniel, >> >> >> FileChannel.open(WRITE,APPEND) could throw NoSuchFileException during a >> startup and shutdown race between two VMs. That case needs to either perform >> a bounded retry or continue and rotate. > > Hi Jason, Alan, > > Here is an updated version of the fix that does a bounded > retry (retries once - and if it fails, proceeds with the next > name). I have also added NO_FOLLOW_LINKS - for the case where > we try to open an existing Lockfile, and suppressed the > Files.isWritable check since that will be taken care of by > the call to FileChannel.open. > > http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.01/ > > I also updated the comments to make it clear that the > file could not have been locked by another instance > of FileHandler (since that would have been taken care > of by our global 'locks' synchronization). > > best regards, > > -- daniel > > >> >> >> Jason >> >> ---------------------------------------- >>> Date: Tue, 24 Jun 2014 20:34:46 +0200 >>> From: daniel.fu...@oracle.com >>> To: core-libs-dev@openjdk.java.net >>> CC: jason_mehr...@hotmail.com; alan.bate...@oracle.com >>> Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler >>> >>> 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. >>> >>> best regards, >>> >>> -- daniel >
