I think Robert might have still had LUCENE-436 in the back of his mind.
I think I'll take care of that one soon - I think those finalize() overrides
are no longer missing, and that's the only "issue" in LUCENE-436. I think
finalize()s there are not hurting us, but since they 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
Subject: Re: ThreadLocal leak (was Re: Leaking org.apache.lucene.index.*
objects)
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 issue every couple of months.
On Dec 19, 2006, at 3:25 PM, Mike Klaas wrote:
> 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" about what is going on is counter productive.
>> You can review the JDK source code, and you can run test cases.
>>
>> There is nothing inherently broken in ThreadLocals, and people that
>> keep claiming that are only doing a disservice to the people that
>> make sure Java is a robust and reliable platform.
>
> I didn't observe any maligning of java ThreadLocals in this thread--I
> only noticed questions about lucene's use of them. I can understand
> that you are worried about FUD, but I don't think that is happening
> here, nor are anyone's efforts being disprespected.
>
> -Mike
>
>> On Dec 19, 2006, at 1:41 PM, Yonik Seeley wrote:
>>
>> > 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 ThreadLocals, you can't
>> replace
>> > with instance vars because the stuff put into the Threadlocals
>> isn't
>> > thread safe.
>> > Replace the ThreadLocal stuff with the code that populated it in
>> the
>> > first place.
>> >
>> > So for instance, in TermInfosReader, replace this
>> > private SegmentTermEnum getEnum() {
>> > SegmentTermEnum termEnum = (SegmentTermEnum)enumerators.get();
>> > if (termEnum == null) {
>> > termEnum = terms();
>> > enumerators.set(termEnum);
>> > }
>> > return termEnum;
>> > }
>> >
>> > With this:
>> > private SegmentTermEnum getEnum() {
>> > return terms()
>> > }
>> >
>> >
>> >> 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$CreationPlaceholder
>> >>
>> >> This is related to http://issues.apache.org/jira/browse/LUCENE-651
>> >> (the commit for that patch also happens to coincide with when I
>> >> started seeing the leak).
>> >
>> > I'll take a look into that. Solr hasn't sync'd to that version of
>> > Lucene yet, so we haven't seen this problem of course :-)
>> >
>> > -Yonik
>> >
>> >
>> ---------------------------------------------------------------------
>> > 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]
>>
>>
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
