[ http://issues.apache.org/jira/browse/LUCENE-529?page=all ]
Andy Hind updated LUCENE-529:
-
Attachment: ThreadLocalTest.java
Attached is a test which you can use to see how ThreadLocals are left around.
Getting an out of memory exception depends on a number
Your testcase is invalid.
Reduce the size by 10, increase the repeat by 10, (SAME amount of memory use),
and it works fine.
The reason it works in the one case is that you use new WeakReference(new
Arrary()), - since the array cannot be referenced, it is immediately GC'd. You
should have notic
The only other thing that may be causing your problem is the use of finalize().
This can interfere with the GC ability to GC objects.
I am not sure why the finalize() is used in the Lucene ThreadLocal handling. It
doesn't seem necessary to me.
-Original Message-
From: Robert Engels [mai
Well, unfortunately, it is your test case that is not equivalent.
OK you make 10 times as many objects that are 1/10 the size.
But the thread local map is the same size and likely to end up holding
the same number of stale entries, so yes the memory footprint is 10
times smaller and it works.
If
The testcase is still not correct - at least with regards to Lucene.
Review the ThreadLocal and ThreadLocalMap code again, you will see that
references to the ThreadLocal are kept using weak references, in a slot in
an array, and entries are reclaimed() (i.e. the slot cleared) PERIODICALLY
as new
: Any suggestions on what to do then, as the following query exhibits the same
behavior
:
: (+cat) (-dog)
:
: Due to the implied AND. Removing the parenthesis allows it to work. It
: doesn't seem that adding parenthesis in this case should cause the query
: to fail???
Adding parens causes QueryPa
