lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erich Eichinger" <E.Eichin...@diamonddogs.cc>
Subject RE: [jira] Commented: (LUCENENET-40) Memory leaks in 1.9.1-004-27Nov06 from Thread-Local Storage
Date Tue, 05 Jun 2007 21:34:26 GMT

Hi,

> Do you have any idea what changed between 1.9 and 2.0 so that 
> these leaks were fixed? 

Atm I can only roughly tell from my mind: They fixed a couply of missing Close() calls and
added some code to remove the instances from the cache.

I can't tell exactly since I only ran some tests testing for memory leaks that failed miserably
with 1.4.3 but passed without problems with 2.0. Thus I didn't look into 2.0 sources too much
then.

> Ok, then what is the intended behavior of the TLS?

Of course the intended behaviour is per thread caching. But some cache items (I remember SegmentReader
or something like that) are specific to a certain Reader/Writer instance and become "orphan"
if the corresponding Reader/Writer is closed. Those items remain in the cache until the process
shuts down.
I remember that in the original Java code a WeakHashMap was used that didn't prevent those
cacheitems from being GCed. But the .NET port used a normal Hashtable instead in version 1.4.3
which caused a couple of those memory leaks.

-Erich

> -----Original Message-----
> From: Joe Shaw [mailto:joe@joeshaw.org] 
> Sent: Tuesday, June 05, 2007 11:21 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (LUCENENET-40) Memory leaks in 
> 1.9.1-004-27Nov06 from Thread-Local Storage
> 
> Hi Erich,
> 
> On 6/5/07, Erich Eichinger <E.Eichinger@diamonddogs.cc> wrote:
> > I posted a patch for 1.4.3 on 7.March'07 to this 
> mailinglist. Some of the leaks fixed by this patch also 
> affect 1.9 asfaik. Lucene 2.0 doesn't have these memory-leaks anymore.
> 
> Do you have any idea what changed between 1.9 and 2.0 so that 
> these leaks were fixed?
> 
> > > > This is an issue that seems to come up a lot.  I'm not 100%
> > > on this, but I believe this is the intended behavior.
> >
> > i know from writing my patches that this is not the 
> intended behaviour. Data stored in the various caches is not 
> reused after closing the reader/writer. Much worse since 
> Reader/Writer instances are used as keys in the Hashtable, 
> any filehandle they hold will never be closed.
> 
> Ok, then what is the intended behavior of the TLS?
> 
> Joe
> 
Mime
View raw message