Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 84489 invoked from network); 11 Sep 2008 20:52:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Sep 2008 20:52:38 -0000 Received: (qmail 22848 invoked by uid 500); 11 Sep 2008 20:52:32 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 22816 invoked by uid 500); 11 Sep 2008 20:52:32 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 22807 invoked by uid 99); 11 Sep 2008 20:52:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Sep 2008 13:52:32 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Sep 2008 20:51:42 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 9921C234C1D7 for ; Thu, 11 Sep 2008 13:51:44 -0700 (PDT) Message-ID: <1885461489.1221166304619.JavaMail.jira@brutus> Date: Thu, 11 Sep 2008 13:51:44 -0700 (PDT) From: "Michael McCandless (JIRA)" To: java-dev@lucene.apache.org Subject: [jira] Created: (LUCENE-1383) Workaround ThreadLocal's "leak" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Workaround 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: 2.3.2, 2.3.1, 2.3, 2.2, 2.1, 2.0.0, 1.9 Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 2.4 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