JDK-6774110 lock file is not deleted when child logger is used
Daniel Fuchs
daniel.fuchs at oracle.com
Thu Oct 9 20:59:43 UTC 2014
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
More information about the core-libs-dev
mailing list