This behavior is a bit strange in that SegmentReader keeps the file open (thus it cannot be deleted) while the thread is alive. Also, you never know when GC is going to kick in, so the file will not be available for deletion until GC happens. Also, see the a couple of emails from the beginning of the March, another person has found this leak with the help of profiler.
Anyway, this change fixed my local problem so I thought to share it 8-) Regards, Volodymyr. ----- Original Message ---- From: Joe Shaw <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, March 29, 2007 8:20:15 PM Subject: Re: Possible leaks in SegmentReader and TermInfosReader Hi, On 3/29/07, Vova Tymchenko <[EMAIL PROTECTED]> wrote: > The trouble that I see with SegmentReader (and TermInfosReader as well) is > that it stores references > to TermVectorsReader in ThreadLocalStore when GetTermVectorsReader is called, > but .Close method fails > to close and clean up that reference. I believe the idea here (at least for TermInfosReader) is to cache that object so that multiple searches on the same thread do not have to continuously reopen the term info file, which can be a pretty big performance hit. Removing the reference in DoClose() will effectively undo this optimization. I think that the references to the data stored in the ThreadLocalStore will be GCable once the thread containing it dies. There was a recent thread about this on the java-dev list, in which someone thought that ThreadLocals were causing a leak, but it turned out to be a bug in the user's code: http://www.archivum.info/[email protected]/2006-12/msg00273.html Joe ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/
