lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: ThreadLocal leak (was Re: Leaking org.apache.lucene.index.* objects)
Date Mon, 18 Dec 2006 02:22:05 GMT
I think that Otis originally said that the problem came up when he 
started using the latest build off of the trunk. I don't believe he 
experienced the problem on 2.0. Anyone on the bleeding edge not noticing 
the leak? I am going to be deploying with 2.trunk soon and am very 
interested <G>.

robert engels wrote:
> Our search server also used long-lived threads. No memory problems 
> whatsoever.
> On Dec 17, 2006, at 3:51 PM, Paul Smith wrote:
>> On 16/12/2006, at 6:15 PM, Otis Gospodnetic wrote:
>>> Moving to java-dev, I think this belongs here.
>>> I've been looking at this problem some more today and reading about 
>>> ThreadLocals.  It's easy to misuse them and end up with memory 
>>> leaks, apparently... and I think we may have this problem here.
>>> The problem here is that ThreadLocals are tied to Threads, and I 
>>> think the assumption in TermInfosReader and SegmentReader is that 
>>> (search) Threads are short-lived: they come in, scan the index, do 
>>> the search, return and die.  In this scenario, their ThreadLocals go 
>>> to heaven with them, too, and memory is freed up.
>> Otis, we have an index server being served inside Tomcat, where an 
>> Application instance makes a search request via vanilla HTTP post, so 
>> our connector threads definitely do stay alive for quite a while.  
>> We're using Lucene 2.0, and our Index server is THE most stable of 
>> all our components, up for over month (before being taken down for 
>> updates) searching hundreds of various sized indexes sized up to 7Gb 
>> in size, serving 1-2 requests/second during peak usage.
>> No memory leak spotted at our end, but I'm watching this thread with 
>> interest! :)
>> cheers,
>> Paul Smith
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message