Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <1449776191.1235736492843.JavaMail.jira@brutus>
Date: Fri, 27 Feb 2009 04:08:12 -0800 (PST)
From: "Robert Starzer (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-1186) [PATCH] Clear ThreadLocal instances
 in close()
In-Reply-To: <873669842.1203677779340.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/LUCENE-1186?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D126=
77340#action_12677340 ]=20

Robert Starzer commented on LUCENE-1186:
----------------------------------------

great! thanks!
IMHO, some kind of IOC container for these lifecycle/caching challenges wou=
ld make it more transparent - or setting some strategy for different enviro=
nments

> [PATCH] Clear ThreadLocal instances in close()
> ----------------------------------------------
>
>                 Key: LUCENE-1186
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1186
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 2.3, 2.3.1, 2.4
>         Environment: any
>            Reporter: Christian Kohlsch=C3=BCtter
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 2.4.1, 2.9
>
>         Attachments: LUCENE-1186-SegmentReader.patch, LUCENE-1186.patch, =
LUCENE-1186.patch
>
>
> As already found out in LUCENE-436, there seems to be a garbage collectio=
n problem with ThreadLocals at certain constellations, resulting in an OutO=
fMemoryError.
> The resolution there was to remove the reference to the ThreadLocal value=
 when calling the close() method of the affected classes (see FieldsReader =
and TermInfosReader).
> For Java < 5.0, this can effectively be done by calling threadLocal.set(n=
ull); for Java >=3D 5.0, we would call threadLocal.remove()
> Analogously, this should be done in *any* class which creates ThreadLocal=
 values
> Right now, two classes of the core API make use of ThreadLocals, but do n=
ot properly remove their references to the ThreadLocal value
> 1. org.apache.lucene.index.SegmentReader
> 2. org.apache.lucene.analysis.Analyzer
> For SegmentReader, I have attached a simple patch.
> For Analyzer, there currently is no patch because Analyzer does not provi=
de a close() method (future to-do?)

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org