Hi,
I have logged https://bugs.openjdk.java.net/browse/JDK-8060132.
I will start a new thread for discussing this issue.
best regards,
-- daniel
On 10/10/14 10:02, Stanimir Simeonoff wrote:
Hi,
LogManager.reset() should invoke a package private method to delete all
lock files. However, that would require holding the FileHandler.locks
monitor during the resetting of FileHandlers, not just the deletion
process. Something like that, plus new PrivilegedAction().
static void deleteAllLocks(){
synchronized(locks){
for (String file : locks) new File(file).delete();
locks.clear();
}
}
Alternatively the deletion could just be part of the Cleaner
shutdownhook with another sun.misc.Cleaner per FileHandler that deletes
the file. (Handlers can be shared amongst loggers, so they cannot be
closed explicitly). There is a certain risk as file.delete() can be a
very slow operation, though (ext3 [concurrently] deleting large files
for example).
Stanimir
On Thu, Oct 9, 2014 at 4:59 PM, Daniel Fuchs <daniel.fu...@oracle.com
<mailto:daniel.fu...@oracle.com>> wrote:
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
