lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Shaw (JIRA)" <>
Subject [jira] Commented: (LUCENENET-40) Memory leaks in 1.9.1-004-27Nov06 from Thread-Local Storage
Date Tue, 05 Jun 2007 19:06:26 GMT


Joe Shaw commented on LUCENENET-40:

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.

Loading the TermInfosReader and SegmentReaders off of the disk is an expensive operation,
and the thread local storage is an optimization to prevent it from happening repeatedly. 
If you have a single search thread, this data is kept in memory and reused on demand; there
is no reason to constantly release and then reload that data whenever another search is started.
 If you have short-lived multiple threads, this data is fairly quickly cleaned up by the GC
when the thread dies.  The only situation in which this should be a real problem is when you
have long-lived threads which might rarely do searches but spend most of its time doing other

The finalizer stuff was a hold over from the Java version, because some versions of the JVM
wouldn't release the thread local data when the thread died.  When that code was migrated
into Lucene.Net, it actually *caused* a mem leak on MS.NET 1.1, if I recall correctly, because
of a runtime bug.

Maybe the right thing to do is to make this optional behavior, because if you have short-lived
searching threads, you probably don't want this data to be cached, and want to release it
as soon as possible.

> Memory leaks in 1.9.1-004-27Nov06 from Thread-Local Storage
> -----------------------------------------------------------
>                 Key: LUCENENET-40
>                 URL:
>             Project: Lucene.Net
>          Issue Type: Bug
>         Environment: Windows XP, .NET 1.1
>            Reporter: zarquon78
> In both TermInfosReader and SegmentReader, the call to System.Threading.Thread.SetData()
to release the data is no longer performed.  This leads to the data remaining attached to
the thread.  This call is in the now commented-out finalized.  By adding the call to the Close()
or DoClose() method, the leak is removed.
> I.e.,
> // TermInfosReader.cs
> public /*internal*/ void Close()
> {
>    // ...
>    System.Threading.Thread.SetData(enumerators, null);  // Added
> }
> // SegmentReader.cs
> protected internal override void DoClose()
> {
>    // ...
>   System.Threading.Thread.SetData(termVectorsLocal, null);  // Added
> }

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message