lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Busch (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-669) finalize()-methods of FSDirectory.FSIndexInput and FSDirectory.FSIndexOutput try to close already closed file
Date Sat, 11 Nov 2006 00:35:39 GMT
    [ 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message