lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert engels (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1383) Work around ThreadLocal's "leak"
Date Wed, 01 Oct 2008 16:57:46 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636095#action_12636095
] 

robert engels commented on LUCENE-1383:
---------------------------------------

You cannot control this 'externally", since there is no way to force the cleaning of the stale
entries (no API method).

The current patch sort of allows this - the entries are not cleared but the weak references
in them are - via the close(), but if this method is called at the wrong time, everything
will break (since the stream needs to be cached), thus it is not exposed to the outside world.

If you want to cleanup programatically, close the index readers and writers.



> Work around ThreadLocal's "leak"
> --------------------------------
>
>                 Key: LUCENE-1383
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1383
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 1.9, 2.0.0, 2.1, 2.2, 2.3, 2.3.1, 2.3.2
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 2.4
>
>         Attachments: LUCENE-1383.patch, ScreenHunter_01 Sep. 13 08.40.jpg, ScreenHunter_02
Sep. 13 08.42.jpg, ScreenHunter_03 Sep. 13 08.43.jpg, ScreenHunter_07 Sep. 13 19.13.jpg
>
>
> Java's ThreadLocal is dangerous to use because it is able to take a
> surprisingly very long time to release references to the values you
> store in it.  Even when a ThreadLocal instance itself is GC'd, hard
> references to the values you had stored in it are easily kept for
> quite some time later.
> While this is not technically a "memory leak", because eventually
> (when the underlying Map that stores the values cleans up its "stale"
> references) the hard reference will be cleared, and GC can proceed,
> its end behavior is not different from a memory leak in that under the
> right situation you can easily tie up far more memory than you'd
> expect, and then hit unexpected OOM error despite allocating an
> extremely large heap to your JVM.
> Lucene users have hit this many times.  Here's the most recent thread:
>   http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200809.mbox/%3C6e3ae6310809091157j7a9fe46bxcc31f6e63305fcdc%40mail.gmail.com%3E
> And here's another:
>   http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200807.mbox/%3CF5FC94B2-E5C7-40C0-8B73-E12245B91CEE%40mikemccandless.com%3E
> And then there's LUCENE-436 and LUCENE-529 at least.
> A google search for "ThreadLocal leak" yields many compelling hits.
> Sun does this for performance reasons, but I think it's a terrible
> trap and we should work around it with Lucene.

-- 
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


Mime
View raw message