lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "zarquon78 (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENENET-40) Memory leaks in 1.9.1-004-27Nov06 from Thread-Local Storage
Date Tue, 05 Jun 2007 20:24:26 GMT

    [ https://issues.apache.org/jira/browse/LUCENENET-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501685
] 

zarquon78 commented on LUCENENET-40:
------------------------------------

Sorry, but I should have mentioned that I was creating an index and not searching...  

The problem was that the amount of memory being used (even after forcing a GC) was continually
increasing.  Since the same thread was doing the indexing, this memory was never being cleaned
up (or so it appears).

While I agree the GC will get the memory when the thread ends, it would seem to be a bad idea
to NOT clean up the memory.  Unless I'm completely missing something, allocating a new SegmentReader
(for example) wouldn't be guarenteed to return the same LocalDataStoreSlot, right?  If the
program continually opens and closes the index in the same thread, won't we get a leak?

If the idea was to store information across instances of SegmentReader and TermInfosReader
so they could be 'closed', wouldn't a static cache object using TLS with named slots be better?
 That way, you're guaranteed to get the data back.

I must be missing something.  It appears that once you release all references to them, you
can never can the data back...  If I'm wrong, just say so.  This isn't the forum for "educating"
me on it.




> Memory leaks in 1.9.1-004-27Nov06 from Thread-Local Storage
> -----------------------------------------------------------
>
>                 Key: LUCENENET-40
>                 URL: https://issues.apache.org/jira/browse/LUCENENET-40
>             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.


Mime
View raw message