[ http://issues.apache.org/jira/browse/LUCENE-669?page=comments#action_12454098 ] Michael McCandless commented on LUCENE-669: -------------------------------------------
OK I will try to repro. In the meantime, I like your theory above! It seems very plausible that the 2nd close (during finalize) could [incorrectly] close what was in fact a newly opened descriptor (in use elsewhere). This also means this bug is more serious that I had thought (I thought it would just throw exceptions up to the GC). One way to be sure this theory is true is to instrument the finalize() to see that indeed it called close for the second time, and, the close succeeded (instead of throwing the original exception you saw). Ie, if this event occurs and then corresponds to the above exception in the TestStressIndexing unit test, then we've got this explained, and, it's quite serious since in production this could in theory result in errant IOExceptions like the one above. > 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 > Assigned To: Michael Busch > Priority: Trivial > Attachments: FSDirectory_close_file2.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]
