Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 56747 invoked from network); 2 Feb 2010 13:59:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Feb 2010 13:59:38 -0000 Received: (qmail 30585 invoked by uid 500); 2 Feb 2010 13:59:35 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 30505 invoked by uid 500); 2 Feb 2010 13:59:35 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 30494 invoked by uid 99); 2 Feb 2010 13:59:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Feb 2010 13:59:34 +0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=RDNS_NONE X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 02 Feb 2010 13:59:25 +0000 Received: (qmail 56624 invoked by uid 99); 2 Feb 2010 13:59:04 -0000 Received: from localhost.apache.org (HELO gv-out-0910.google.com) (127.0.0.1) (smtp-auth username cleclerc, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Feb 2010 13:59:04 +0000 Received: by gv-out-0910.google.com with SMTP id n29so581gve.39 for ; Tue, 02 Feb 2010 05:59:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.102.183.14 with SMTP id g14mr3755058muf.71.1265119142611; Tue, 02 Feb 2010 05:59:02 -0800 (PST) X-Originating-IP: [86.65.15.100] In-Reply-To: <4B682C57.70602@apache.org> References: <4B682933.1070104@villeinitalia.com> <4B682C57.70602@apache.org> Date: Tue, 2 Feb 2010 14:59:02 +0100 Message-ID: <1db564171002020559j5dd27c8et76c9bfbd5c6efc89@mail.gmail.com> Subject: Re: Threadlocal problem From: Cyrille Le Clerc To: Tomcat Users List Content-Type: text/plain; charset=ISO-8859-1 Hello, Your threadLocal variable is created by the reflectionToString feature of Jakarta Commons Lang ToStringBuilder (1). This thread local variable seems to be used to prevent infinite recursion when ToStringBuilder traverse the objects. I didn't see yet a way (servlet filter, etc) to cleanup this ThreadLocal. Cyrille -- Cyrille Le Clerc cleclerc@xebia.fr (1) http://fisheye6.atlassian.com/browse/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java?r=594386#l136 On Tue, Feb 2, 2010 at 2:44 PM, Mark Thomas wrote: > > On 02/02/2010 13:31, Malcolm Warren wrote: > > SEVERE: A web application created a ThreadLocal with key of type > > [org.apache.commons.lang.builder.ToStringStyle$1] (value > > [org.apache.commons.lang.builder.ToStringStyle$1@66a37d72]) and a value > > of type [java.util.HashSet] (value [[]]) but failed to remove it when > > the web application was stopped. To prevent a memory leak, the > > ThreadLocal has been forcibly removed. > > > > > > > > I get this message with every hot redeploy, which is a little worrying. > > Anybody know what it's about? > > The message says it all. Something created a ThreadLocal but didn't > clean it up. Tomcat cleaned it up to prevent a memory leak. > > > This started with the latest Tomcat 6 version: 6.0.24. > > I'm pleased with this new version because it also pointed out politely > > that I hadn't closed a thread I'd opened. > > This is all part of the new memory leak protection added for 6.0.24. It > is good to hear that people are finding it useful. > > > I've fixed my Thread but I still get the message shown at the beginning > > of this email. > > > > I don't use ThreadLocal in my code at all, so it's Tomcat who's creating > > this ThreadLocal for some reason, but since it's not mine it's something > > I can't do much about, presumably. > > It isn't Tomcat's (Tomcat doesn't ship with commons-lang) so I am pretty > sure it is yours. Chances are it isn't something you are doing directly > but maybe something a library you are using is doing? > > If a library is adding a ThreadLocal to a request processing thread it > *must* remove it before the request completes to avoid a potential > memory leak. If it doesn't, I would argue that is a bug in the library. > At a stretch, if the library provides a mechanism to clean these up on > web app shutdown that is just about OK but that could would need to be > carefully coded. > > Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org