[jira] Commented: (LUCENE-823) Lucene fails to close file handles under certain situations

["Yonik Seeley (JIRA)" <ji...@apache.org>]

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

Yonik Seeley commented on LUCENE-823:
-------------------------------------

> TermInfosReader.close() was setting its ThreadLocal enumerators to
 >  null without first closing the SegmentTermEnum in there.

Are you sure descriptors are really leaked in this case?
There are other cases where Lucene doesn't close IndexInput clones... see LUCENE-686

The SegmentTermEnum constructor is only called in two places:
 - to init TermInfosReader.origEnum
 - to init TermInfosReader.indexEnum

We can therefore conclude that all other SegmentTermEnum instances are clones, and hence close is a no-op.

> 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