Hi Stanimir, Jason, 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(); } }
There's more than the deletion of the lock file unfortunately. I believe the handlers should be properly closed. A handler with an XMLFormatter for instance needs to write the tail of the file.
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).
That's a solution I envisaged and rejected because of the constraints we have when running in the ReferenceHandler thread. I don't think it would be appropriate to close a Handler in that thread. I'm leaning towards suggesting that the LogManager should hold a strong reference on the loggers for which a Handler is explicitly configured in the configuration file. It would ensure that these loggers are still around when reset() is called. best regards, -- daniel
Stanimir On Thu, Oct 9, 2014 at 4:59 PM, Daniel Fuchs <[email protected] <mailto:[email protected]>> 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
