lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <>
Subject [jira] Commented: (LUCENE-823) Lucene fails to close file handles under certain situations
Date Sun, 04 Mar 2007 20:07:50 GMT


Yonik Seeley commented on LUCENE-823:

> guess I'll leave the close in there

Since it's a thread-local, that only closes (maybe) for a single thread.
Doesn't seem worth it, and could be misleading to anyone thinking it closed all the enumerators.

> Lucene fails to close file handles under certain situations
> -----------------------------------------------------------
>                 Key: LUCENE-823
>                 URL:
>             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:
For additional commands, e-mail:

View raw message