lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <>
Subject Re: [jira] Commented: (LUCENE-686) Resources not always reclaimed in scorers after each search
Date Wed, 18 Oct 2006 07:12:17 GMT
On Wednesday 18 October 2006 06:21, Chris Hostetter wrote:
> : > : When custom Scorers and/or Directories need a close method, it can
> : > : also be provided by subclassing Scorer, IndexSearcher and Directory
> : > it seems like that would handicap adoption of new 
Queries/Directories ...
> : > I don't know how many people would have been interested in
> : > ConstantScoreQuery or FunctionQuery if they'd been told they had to stop
> : > using IndexSearcher and start using a new 
> :
> : Iirc no (general) closing method in Scorer or IndexSearcher was needed
> : for the Constant... and Function... queries and scorers.
> that's kind of side stepping my point: those classes gained popularity and
> use because they were easy to adopt -- they didn't have any complex
> dependencies, and could be droped into an existing Lucene application and
> be used without any other changes.  If they *had* needed maintain
> resources, and that had forced the creation of custom IndexSearchers, no
> one would have ever tried them out -- hence my point that your suggested
> workarround would handicap the creation of new more complex Scorers and
> Directories.
> The bottom line is:
>  1) TermDocs has a close method
>  2) anything implimenting TermDocs should be able to trust that
>     close() will be called
>  3) anything iterating over a TermDocs should call close()
> ...ergo: TermScorer needs a close() method, right?

There is no memory leak now, and TermDocs.close() is not always
called, so I'd rather conclude that a close() method is not really
It might be nice to release resources early, but the garbage collector
can also do that later, and perhaps even more efficiently.
When it turns out that using close() during search helps performance
in some cases, I'd like to know about them.

Paul Elschot

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

View raw message