Just chipping in that I recall there being a number of discussions on
java-dev about ThreadLocal and web containers and how they should be
handled. Not sure if it pertains here or not, but you might find http://lucene.markmail.org/message/keosgz2c2yjc7qre?q=ThreadLocal
helpful.
You might also consider asking on java-dev in this case, which usually
isn't recommended, but this is pretty low-level stuff and seems more
appropriate there. It does seem like a problem though and I'm not
sure of the alternative just yet.
On Sep 7, 2008, at 1:35 AM, Chris Lu wrote:
Unless my understanding is wrong, there is a memory leak for Lucene
search
from Lucene-1195.(svn r659602, May23,2008)
This patch brings in a ThreadLocal cache to TermInfosReader.
It's usually recommended to keep the reader open, and reuse it when
possible. In a common J2EE application, the http requests are usually
handled by different threads. But since the cache is ThreadLocal,
the cache
are not really usable by other threads. What's worse, the cache can
not be
cleared by another thread!
This leak is not so obvious usually. But my case is using
RAMDirectory,
having several hundred megabytes. So one un-released resource is
obvious to
me.
Here is the reference tree:
org.apache.lucene.store.RAMDirectory
|- directory of org.apache.lucene.store.RAMFile
|- file of org.apache.lucene.store.RAMInputStream
|- base of org.apache.lucene.index.CompoundFileReader
$CSIndexInput
|- input of org.apache.lucene.index.SegmentTermEnum
|- value of java.lang.ThreadLocal$ThreadLocalMap
$Entry
After I switched back to svn revision 659601, right before this
patch is
checked in, the memory leak is gone.
Although my case is RAMDirectory, I believe this will affect disk
based
index also.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
