Bingo! :) I'll try the patch shortly and report back in a bit. What do you think about that alternative approach I mentioned? Instead of having FieldCacheImpl be aware of all IndexReaders, have FieldCache be an inst var in IndexReader? That way we can clean up/lose reference to FieldCache when we close IndexReader instead of relying on GC to clean up IndexReaders from FieldCacheImpl's WeakHashMap. Wouldn't that simplify the code? I think we wouldn't have to have some of those caches in FieldCacheImpl then.
Thanks, Otis ----- Original Message ---- From: Yonik Seeley <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Tuesday, December 19, 2006 2:50:43 PM Subject: Re: ThreadLocal leak (was Re: Leaking org.apache.lucene.index.* objects) On 12/19/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: > On 12/19/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: > > What I'm seeing while profiling (and in production) is the accumulation of > > these: > > > > org.apache.lucene.search.FieldCacheImpl$Entry > > org.apache.lucene.search.FieldCacheImpl$CreationPlaceholder > > > > This is related to http://issues.apache.org/jira/browse/LUCENE-651 (the > > commit for that patch also happens to coincide with when I started seeing > > the leak). > > I'll take a look into that. Solr hasn't sync'd to that version of > Lucene yet, so we haven't seen this problem of course :-) OK, I see the problem... I opened http://issues.apache.org/jira/browse/LUCENE-754 to track and it should hopefully be fixed soon -- -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
