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:[EMAIL PROTECTED] 
> Sent: Tuesday, June 05, 2007 11:21 PM
> To: [email protected]
> 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 <[EMAIL PROTECTED]> 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
> 

Reply via email to