We acquired a product with about a million lines of code. The original author had no formal software design education and had ported the product from Pascal to C++ to Java EE. There are many interesting designs in the code, and no separation of control by any measure. We have a multi-year roadmap in place to reengineer the software, but it’s going to be a gradual process, and the transition will involve many temporary “hacks” so to speak.
The use of ThreadLocals in several places helps us achieve the reengineering in that we can design interfaces now that don’t require us to pass around some of the “God objects” we’re trying to get rid of, while still using them in the temporary implementations of these interfaces. Unfortunately, the use of ThreadLocals was, at first, rather halphazard and uneducated by some members of the team. With that said, after spending about another day looking through code, there really just were a few other places that ThreadLocals were being set() but not remove()d. I have now resolved all memory leak issues Tomcat was reporting. This will be followed up by a heavy dose of education for the team about when it is and isn’t appropriate to use ThreadLocals during this reengineering phase. Thanks for responding! Nick -- *Nick Williams |* Senior Software Developer *UL PureSafety* Health & Safety Software Solutions Toll Free: 888.202.3016 x 177 | Direct: 615.277.3177 | Fax: 615.367.3887 730 Cool Springs Blvd, Suite 400 | Franklin, TN 37067 | www.puresafety.com | www.ul.com ------------------------------ *UL acquired PureSafety on December 6, 2011. Learn More.<http://www.puresafety.com/public/knowledge-exchange/news/2011/12/06/ul-expands-occupational-health-safety-presence-training-capabilit> * -----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Sunday, February 26, 2012 8:45 PM To: Tomcat Users List Subject: Re: SEVERE: The web application created a ThreadLocal (but I removed it) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nick, On 2/22/12 7:52 PM, Nick Williams wrote: > Now, at the end of each request, I am calling: > > threadLocalInstance.set(null); > > threadLocalInstance.remove(); If you are creating a ThreadLocal for each request (that needs the object) and then disposing of it, why bother with the ThreadLocal in the first place? Is this a case of wanting global-variable semantics and just being lazy about (not) passing arguments around? > I’m still getting these four messages, and I can’t seem to get them to > go away. But I have tracked down these specific instances and I > *am* calling set(null) and remove() on these instances. Does it always happen? Perhaps you are encountering an exception and your .remove() isn't being called in certain cases. Consider a 'finally' block? > Is something about the Tomcat code somehow locating “phantom” > references to ThreadLocals that have actually been removed and ARE > really eligible for GC, or am I really just not always clearing those > ThreadLocals and I just still haven’t tracked down the source? Tomcat just looks at the ThreadLocals still left over in a Thread after your webapp is stopped. There's nothing "phantom" about them. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9K7icACgkQ9CaO5/Lv0PBFsgCfT1Y+Mj4C40rwNUAp1wk38e+e m1IAn22T17lUBZAQ3t9zYBoll5TzEL30 =3Ndj -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
