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 "ConstantScorableIndexSearcher" > : > : 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 needed. 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. Regards, Paul Elschot --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
