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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
