Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 88777 invoked from network); 21 Sep 2004 03:28:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 21 Sep 2004 03:28:52 -0000 Received: (qmail 23396 invoked by uid 500); 21 Sep 2004 03:28:48 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 23269 invoked by uid 500); 21 Sep 2004 03:28:48 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 23256 invoked by uid 99); 21 Sep 2004 03:28:47 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [192.18.33.10] (HELO exchange.sun.com) (192.18.33.10) by apache.org (qpsmtpd/0.28) with SMTP; Mon, 20 Sep 2004 20:28:47 -0700 Received: (qmail 2302 invoked from network); 21 Sep 2004 03:30:37 -0000 Received: from localhost (HELO nagoya) (127.0.0.1) by nagoya.betaversion.org with SMTP; 21 Sep 2004 03:30:37 -0000 Message-ID: <2134137703.1095737437591.JavaMail.apache@nagoya> Date: Mon, 20 Sep 2004 20:30:37 -0700 (PDT) From: commons-dev@jakarta.apache.org To: commons-dev@jakarta.apache.org Subject: [jira] Commented: (JELLY-148) Huge memory leak resulting from the use of ThreadLocal In-Reply-To: <1216658644.1095568597560.JavaMail.apache@nagoya> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N The following comment has been added to this issue: Author: Hans Gilde Created: Mon, 20 Sep 2004 8:30 PM Body: Yes, sounds possible. If we go that route, though, then there won't be an easy way to get an API on the cache itself. It'll be something that's totally within the TagScripts using special context variable names. No good way to get at the cache from the outside. --------------------------------------------------------------------- View this comment: http://issues.apache.org/jira/browse/JELLY-148?page=comments#action_53271 --------------------------------------------------------------------- View the issue: http://issues.apache.org/jira/browse/JELLY-148 Here is an overview of the issue: --------------------------------------------------------------------- Key: JELLY-148 Summary: Huge memory leak resulting from the use of ThreadLocal Type: Bug Status: Unassigned Priority: Critical Project: jelly Components: core / taglib.core Versions: 1.0-beta-5 Assignee: Reporter: Hans Gilde Created: Sat, 18 Sep 2004 9:34 PM Updated: Mon, 20 Sep 2004 8:30 PM Description: There is a huge memory leak that results from the TagScript's use of ThreadLocal. ThreadLocal is usually used from a staic variable, while TagScript uses it from an instance variable. Although this looks legal to me, it causes a huge memory leak. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org