[ http://issues.apache.org/jira/browse/LUCENE-669?page=comments#action_12448908 ] Michael Busch commented on LUCENE-669: --------------------------------------
The method closeFile() belongs to FSDirectory.FSIndexOutput, so I can't call it in FSDirectory.FSIndexInput.close(). (This is hard to see if you just look at the patch file). I added the method closeFile() to FSDirectory.FSIndexOutput, because the behaviour of finalize() and close() is slightly different: finalize() simply closes the file, whereas close() calls super.close() first and closes the file then. I didn't want to change this behavior, thus I can't just call close() from finalize(). But now I am actually wondering if this behavior is correct. super.close() triggers a flush of the buffer. So in the current Lucene code, FSDirectory.FSIndexOutput.close() triggers a flush, but FSDirectory.FSIndexOutput.finalize() doesn't. Shouldn't we call flush also inside finalize() surrounded by try/catch? > finalize()-methods of FSDirectory.FSIndexInput and FSDirectory.FSIndexOutput > try to close already closed file > ------------------------------------------------------------------------------------------------------------- > > Key: LUCENE-669 > URL: http://issues.apache.org/jira/browse/LUCENE-669 > Project: Lucene - Java > Issue Type: Bug > Components: Store > Reporter: Michael Busch > Priority: Trivial > Attachments: FSDirectory_close_file_patch.patch > > > Hi all, > I found a small problem in FSDirectory: The finalize()-methods of > FSDirectory.FSIndexInput and FSDirectory.FSIndexOutput try to close the > underlying file. This is not a problem unless the file has been closed before > by calling the close() method. If it has been closed before, the finalize > method throws an IOException saying that the file is already closed. Usually > this IOException would go unnoticed, because the GarbageCollector, which > calls finalize(), just eats it. However, if I use the Eclipse debugger the > execution of my code will always be suspended when this exception is thrown. > Even though this exception probably won't cause problems during normal > execution of Lucene, the code becomes cleaner if we apply this small patch. > Might this IOException also have a performance impact, if it is thrown very > frequently? > I attached the patch which applies cleanly on the current svn HEAD. All > testcases pass and I verfied with the Eclipse debugger that the IOException > is not longer thrown. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
