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 clecl...@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 <ma...@apache.org> 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.tostringstyl...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
