lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-823) Lucene fails to close file handles under certain situations
Date Sun, 04 Mar 2007 19:57:50 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477852
] 

Michael McCandless commented on LUCENE-823:
-------------------------------------------

Ahh, tricky!

You are right, this is not a real leak, since it's a clone that's
failing to be closed and since FSIndexInput does not make a clone of
the underlying file descriptor.

I had assumed/expected that a clone must be closed, but I guess it's
[currently] a no-op.  This is the heart of the debate in LUCENE-686.

I guess I'll leave the close in there, but change MockRAMDirectory to
ignore still-open clones when the dir is closed and add a comment
about this LUCENE-686.


> Lucene fails to close file handles under certain situations
> -----------------------------------------------------------
>
>                 Key: LUCENE-823
>                 URL: https://issues.apache.org/jira/browse/LUCENE-823
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 2.1
>            Reporter: Michael McCandless
>         Assigned To: Michael McCandless
>            Priority: Minor
>             Fix For: 2.2
>
>         Attachments: LUCENE-823.patch
>
>
> As a followon to LUCENE-820, I've added a further check in
> MockRAMDirectory to assert that there are no open files when the
> directory is closed.
> That check caused a few unit tests to fail, and in digging into the
> reason I uncovered these cases where Lucene fails to close file
> handles:
>   * TermInfosReader.close() was setting its ThreadLocal enumerators to
>     null without first closing the SegmentTermEnum in there.  It looks
>     like this was part of the fix for LUCENE-436.  I just added the
>     call to close.
>     This is somewhat severe since we could leak many file handles for
>     use cases that burn through threads and/or indexes.  Though,
>     FSIndexInput does have a finalize() to close itself.
>   * Flushing of deletes in IndexWriter opens SegmentReader to do the
>     flushing, and it correctly calls close() to close the reader.  But
>     if an exception is hit during commit and before actually closing,
>     it will leave open those handles.  I fixed this first calling
>     doCommit() and then doClose() in a finally.  The "disk full" tests
>     we now have were hitting this.
>   * IndexWriter's addIndexes(IndexReader[]) method was opening a
>     reader but not closing it with a try/finally.  I just put a
>     try/finally in.
> I've also changed some unit tests to use MockRAMDirectory instead of
> RAMDirectory to increase testing coverage of "leaking open file
> handles".

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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