: > What do you think about that alternative approach I mentioned? Instead of
having FieldCacheImpl be aware of all IndexReaders, have FieldCache be an inst
var in IndexReader?
:
: I wonder why it wasn't done that way to start with perhaps to
: completely separate sorting from index reading
ey contain hacks for
pre-1.4.2 JVMs, we could clean that up now. FixedThreadLocal.java that's
attach there won't be needed.
Otis
- Original Message
From: robert engels <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Tuesday, December 19, 2006 4:52:18 PM
S
Sorry, it wasn't this particular thread. Sorry for the confusion.
This thread is actually on the money I believe (The FieldCache issues).
I got my wires crossed during a vent. It is just difficult when you
spend numerous hours to diagnose "the problem" and then have to
revisit the same issu
On 12/19/06, robert engels <[EMAIL PROTECTED]> wrote:
I would suggest that in order to even bring up "thread local issues"
in the future that the submitter supplies a pure Java NON-LUCENE test
case that demonstrates the problem (just as you would if reporting a
bug to Sun).
All of the "guessing"
I would suggest that in order to even bring up "thread local issues"
in the future that the submitter supplies a pure Java NON-LUCENE test
case that demonstrates the problem (just as you would if reporting a
bug to Sun).
All of the "guessing" about what is going on is counter productive.
On 12/19/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
Bingo! :) I'll try the patch shortly and report back in a bit.
Cool, since you can serve as a test-case, I'll hold of on committing
until I hear how it works.
What do you think about that alternative approach I mentioned? Instead of
Yonik Seeley <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Tuesday, December 19, 2006 2:50:43 PM
Subject: Re: ThreadLocal leak (was Re: Leaking org.apache.lucene.index.*
objects)
On 12/19/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On 12/19/06, Otis Gospodnetic <[EMAIL
LOL! of course I stopped to open the bug,
grab a sandwitch, etc ;-)
On 12/19/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
Ha! ... I beat you by 16 whole seconds!
You have to be faster then that if you want to roll with the Big Dogs!
: Date: Tue, 19 Dec 2006 11:50:07 -0800 (PST)
: From: Chris
Ha! ... I beat you by 16 whole seconds!
You have to be faster then that if you want to roll with the Big Dogs!
: Date: Tue, 19 Dec 2006 11:50:07 -0800 (PST)
: From: Chris Hostetter
: Subject: Re: ThreadLocal leak (was Re: Leaking org.apache.lucene.index.*
: Date: Tue, 19 Dec 2006 11:50:23 -080
On 12/19/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 12/19/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
> What I'm seeing while profiling (and in production) is the accumulation of
these:
>
> org.apache.lucene.search.FieldCacheImpl$Entry
> org.apache.lucene.search.FieldCacheImpl$CreationPl
: Can anyone else have a look at the patch for LUCENE-651 (or just at
: FieldCacheImpl) and see if there is a quick fix?
If i'm not mistaken, isn't line #65 wrong? ...
synchronized (readerCache) {
innerCache = (Map) readerCache.get(reader);
if (innerCache == null) {
On 12/19/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
I _think_ Robert is right and ThreadLocals are not the problem (I tried getting
rid of them, and replacing them with an instance var last week, but run into
problems with multi-threaded unit tests).
If you want to try getting rid of the
s to IndexReaders, and doesn't know
when they are closed, and thus it can't remove them and their data from its
internal caches?
Thanks,
Otis
- Original Message
From: Mark Miller <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Sunday, December 17, 2006 9:22:05 PM
There is no inherent problem with ThreadLocal. It is a viable
solution to synchronization issues in most cases.
On Dec 18, 2006, at 11:25 AM, Bernhard Messer wrote:
Otis,
i figured out a similar problem when running a very heavy loaded
search application in a servlet container. The reasone
Otis,
i figured out a similar problem when running a very heavy loaded search
application in a servlet container. The reasone using ThreadLocals was
to get rid of synchronized method calls e.g in TermVectorsReader which
would break down the overall search performance. Currently i do not see
a
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 .
rober
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
ab
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
I can basically GUARANTEE that unless you are using large indexes and
loading into a RamDirectory (and use Java prior to 1.5) , that there
is NO ISSUE in using a ThreadLocal,
There is something else wrong in your application.
PLEASE get a good profiler and perform the required testing. It is
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 Thre
20 matches
Mail list logo
