JDK-6774110 lock file is not deleted when child logger is used

[Jason Mehrens]

Here is a test case.



public class GcOfLogger {

    private static final String CLASS_NAME = GcOfLogger.class.getName();

    public static void main(String[] args) throws Exception {
        File log = new File(CLASS_NAME.concat(".xml"));
        install(log.getCanonicalPath());
        LogManager manager = LogManager.getLogManager();
        boolean cleared = false;
        for (int i = 0; i < 10; i++) {
            if (manager.getLogger(CLASS_NAME) != null) {
                System.runFinalization();
                System.gc();
                System.runFinalization();
                Thread.sleep(200L);
            } else {
                cleared = true;
                break;
            }
        }

        if (!cleared) {
            throw new IllegalStateException();
        }

        File lock = new File(log.getCanonicalPath().concat(".lck"));
        System.out.println(log.delete());
        System.out.println(lock.delete());
    }

    private static void install(String log) throws Exception {
        String path = new File(log).getCanonicalPath();
        Logger logger = Logger.getLogger(CLASS_NAME); //No strong reference.
        logger.addHandler(new FileHandler(path));
    }
}


----------------------------------------
> Date: Thu, 9 Oct 2014 22:59:43 +0200
> From: daniel.fuchs at oracle.com
> To: jason_mehrens at hotmail.com
> CC: core-libs-dev at openjdk.java.net
> Subject: Re: JDK-6774110 lock file is not deleted when child logger is used
>
> Thanks Jason.
>
> I wonder if that may be another issue. Interesting. I'll see if I can
> work out a test case
> for that tomorrow. With the test case provided in the bug - tested on 7,
> 8, and 9,
> the only file that remained at the end was 'log' (which is as it should
> be - and I ran
> the test case several times with each JDK) - which lets me think that
> maybe the
> issue was different.
>
> Now what you describe looks indeed like a bug that should still be present
> in the code base. I didn't think about that scenario, thanks for
> pointing it out!
> If i can write a reproducer (which should not be too difficult), it will
> be a good
> incentive to attempt a fix :-)
>
> Thanks again,
>
> -- daniel
>
> On 10/9/14 9:56 PM, Jason Mehrens wrote:
>> Daniel,
>>
>>
>> The evaluation on this bug is not quite correct. What is going on here is the child logger is garbage collected which makes the FileHandler unreachable from the LogManager$Cleaner which would have closed the attached FileHandler. In the example, there is no hard reference that escapes the 'execute' method. Prior to fixing JDK-6274920: JDK logger holds strong reference to java.util.logging.Logger instances, the LogManager$Cleaner would have deleted the lock file on shutdown. Now that the loggers are GC'able, one possible fix would be change the FileHandler.locks static field to Map<String,FileHandler> where the key is the file name and the value is the FileHandler that is open. Then in the LogManager$Cleaner could close any entries in that map after LogManager.reset() is executed.
>>
>>
>> Jason
>