You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Jeremy Volkman <jv...@gmail.com> on 2009/05/21 16:45:19 UTC

Do TermDocs and TermEnum need to be closed?

Greetings all,

I currently have a FieldExistsFilter which returns all documents that
contain a particular field. I'm in the process of converting my custom
filters to be DocIdSet based rather than BitSet based. This filter, however,
requires the use of a TermDocs object to iterate over terms and
DocIdSetIterator never provides an opportunity to close that TermDocs
object.

I looked at MatchAllDocsQuery which is similar, and noticed that it never
closes its TermDocs object. In SegmentTermDocs' close method isn't a no-op,
however: IndexInput objects are closed.  Would failure to call
SegmentTermDocs.close possibly leave file handles open, or is the lack of a
call to close operating on knowledge that those streams will be closed
elsewhere?

It seems to me that DocIdSetIterator should provide a close to allow usage
of TermDocs, TermEnum, etc. in the iterator while still conforming to the
APIs of those classes.

Thanks,
Jeremy

Re: Do TermDocs and TermEnum need to be closed?

Posted by Jeremy Volkman <jv...@gmail.com>.
Thanks Mike. In the meantime I'll just not close them. :)

On Thu, May 21, 2009 at 12:19 PM, Michael McCandless <
lucene@mikemccandless.com> wrote:

> You're right, SegmentTermDocs/TermEnum.close calls close on its
> IndexInputs, but those IndexInputs were obtained by calling clone() on
> the "real" IndexInputs and so for NIOFSDirectory, FSDirectory and
> RAMDirectory at least, when a clone's close() is called, that's a
> no-op.
>
> I think there are many places in Lucene where we don't close the
> TermDocs/TermPositions so I think you're OK not calling them
> until/unless this situation changes in Lucene.
>
> Probably we should either remove close() entirely (because it sure
> looks like it's supposed to be called), or, call close() from Lucene
> consistently when we use these classes.
>
> Adding close/finish to DISI is an interesting idea... I've added a
> comment here to raise this:
>
>  https://issues.apache.org/jira/browse/LUCENE-1614
>
> Mike
>
> On Thu, May 21, 2009 at 10:45 AM, Jeremy Volkman <jv...@gmail.com>
> wrote:
>
> > I currently have a FieldExistsFilter which returns all documents that
> > contain a particular field. I'm in the process of converting my custom
> > filters to be DocIdSet based rather than BitSet based. This filter,
> however,
> > requires the use of a TermDocs object to iterate over terms and
> > DocIdSetIterator never provides an opportunity to close that TermDocs
> > object.
> >
> > I looked at MatchAllDocsQuery which is similar, and noticed that it never
> > closes its TermDocs object. In SegmentTermDocs' close method isn't a
> no-op,
> > however: IndexInput objects are closed.  Would failure to call
> > SegmentTermDocs.close possibly leave file handles open, or is the lack of
> a
> > call to close operating on knowledge that those streams will be closed
> > elsewhere?
> >
> > It seems to me that DocIdSetIterator should provide a close to allow
> usage
> > of TermDocs, TermEnum, etc. in the iterator while still conforming to the
> > APIs of those classes.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

Re: Do TermDocs and TermEnum need to be closed?

Posted by Michael McCandless <lu...@mikemccandless.com>.
You're right, SegmentTermDocs/TermEnum.close calls close on its
IndexInputs, but those IndexInputs were obtained by calling clone() on
the "real" IndexInputs and so for NIOFSDirectory, FSDirectory and
RAMDirectory at least, when a clone's close() is called, that's a
no-op.

I think there are many places in Lucene where we don't close the
TermDocs/TermPositions so I think you're OK not calling them
until/unless this situation changes in Lucene.

Probably we should either remove close() entirely (because it sure
looks like it's supposed to be called), or, call close() from Lucene
consistently when we use these classes.

Adding close/finish to DISI is an interesting idea... I've added a
comment here to raise this:

  https://issues.apache.org/jira/browse/LUCENE-1614

Mike

On Thu, May 21, 2009 at 10:45 AM, Jeremy Volkman <jv...@gmail.com> wrote:

> I currently have a FieldExistsFilter which returns all documents that
> contain a particular field. I'm in the process of converting my custom
> filters to be DocIdSet based rather than BitSet based. This filter, however,
> requires the use of a TermDocs object to iterate over terms and
> DocIdSetIterator never provides an opportunity to close that TermDocs
> object.
>
> I looked at MatchAllDocsQuery which is similar, and noticed that it never
> closes its TermDocs object. In SegmentTermDocs' close method isn't a no-op,
> however: IndexInput objects are closed.  Would failure to call
> SegmentTermDocs.close possibly leave file handles open, or is the lack of a
> call to close operating on knowledge that those streams will be closed
> elsewhere?
>
> It seems to me that DocIdSetIterator should provide a close to allow usage
> of TermDocs, TermEnum, etc. in the iterator while still conforming to the
> APIs of those classes.

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org