lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Parkes (JIRA)" <>
Subject [jira] Commented: (LUCENE-686) Resources not always reclaimed in scorers after each search
Date Thu, 26 Oct 2006 22:28:18 GMT
    [ ] 
Steven Parkes commented on LUCENE-686:

You're right, and that's actually at the heart of the issue.

Seems like part of what needs to be clarified is what clone() does on an IndexInput. It doesn't
simply make another copy of the IndexInput. The result is neither independent of nor equivalent
to the original. At least for FSIndexInput:

- not equivalent: close on a clone is different then close on the original
- not independent: close on the original impacts the behavior of existing clones

I don't see that that's going to change. The semantics may be a little bit squrrely (and maybe
the name clone() isn't the best, if the result isn't a true clone?), but it's obviously not
causing any problems.

I would think the best thing to do would be just document this existing behavior so it can
be relied on: clones of IndexInputs do not need to be closed and cannot be relied upon if
the clone source is closed.

If/once that's the documented behavior, it's okay to get rid of all the extra close()es. New
implementations of IndexInput just need to abide by that behavior, however they choose to
implement it.

> Resources not always reclaimed in scorers after each search
> -----------------------------------------------------------
>                 Key: LUCENE-686
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Search
>         Environment: All
>            Reporter: Ning Li
>         Attachments: ScorerResourceGC.patch
> Resources are not always reclaimed in scorers after each search.
> For example, close() is not always called for term docs in TermScorer.
> A test will be attached to show when resources are not reclaimed.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


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

View raw message