[ http://issues.apache.org/jira/browse/LUCENE-686?page=comments#action_12444758 ] Steven Parkes commented on LUCENE-686: --------------------------------------
Well, this has been a nice example to drive me into some of the internals. It seems like close() methods are around in most cases to provide determinism in operations that have externally visible side effects, e.g., commits in IndexReader. But it doesn't seem like TermDocs has this type of behavior or is likely to in the foreseeable future? SegmentReader always keeps open handles to the appropriate files anyway. One can certainly posit that someday a version of something will change and TermDocs.close() will do something, but wouldn't YAGNI argue for waiting until that's really the case? I still kinda feel like this half-in/half-out (called sometimes, but not always) is kinda the worst of all worlds: it can't be relied on (not always called) and all those calls that don't do anything are (probably insignificant) wasted time. But the biggest thing is the intellectual drag, where people spend time trying to understand something that at least appears inconsistent. If this reasoning is right, what do people think about just yanking it out? > Resources not always reclaimed in scorers after each search > ----------------------------------------------------------- > > Key: LUCENE-686 > URL: http://issues.apache.org/jira/browse/LUCENE-686 > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
