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>
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
>>
>
>
