lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josef (JIRA)" <>
Subject [jira] [Commented] (LUCENE-2762) Don't leak deleted open file handles with pooled readers
Date Tue, 24 May 2011 17:11:47 GMT


Josef commented on LUCENE-2762:

Thanks for the quick response.

You are right, we just increase the reference for the current Searcher when it is obtained
and used. Decreasing it again is part of a finally block. I have triple checked this code
to make sure, we are not doing anything wrong and I am very sure, we correctly decrease the
reference in any case.

The output of the 'lsof' command above shows handles to files already marked deleted. The
number of files marked deleted increases over time until we get a Java 'IOException: Too many
open files'. 
If we don't hold the reference to the reader contained in our searcher, who is?

Regarding merge factor etc: we are using standard configurations, i.e. no tweaking (yet).
Besides, we do not call IndexWriter.optimize() in our code yet.

> Don't leak deleted open file handles with pooled readers
> --------------------------------------------------------
>                 Key: LUCENE-2762
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>    Affects Versions: 2.9.4, 3.0.3, 3.1, 4.0
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 2.9.4, 3.0.3, 3.1, 4.0
>         Attachments: LUCENE-2762.patch
> If you have CFS enabled today, and pooling is enabled (either directly
> or because you've pulled an NRT reader), IndexWriter will hold open
> SegmentReaders against the non-CFS format of each merged segment.
> So even if you close all NRT readers you've pulled from the writer,
> you'll still see file handles open against files that have been
> deleted.
> This count will not grow unbounded, since it's limited by the number
> of segments in the index, but it's still a serious problem since the
> app had turned off CFS in the first place presumably to avoid risk of
> too-many-open-files.  It's also bad because it ties up disk space
> since these files would otherwise be deleted.

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message