[ http://issues.apache.org/jira/browse/AXIS-935?page=comments#action_61085 ] Catalin Grigoroscuta commented on AXIS-935: -------------------------------------------
Actually, yes, the bug persists on 1.2RC3, althouhg I've seen there was some work done to fix it. I reproduce the bug with a WS server and a client running in the same web application (the client is actually a jsp). I've made a screenshot with the profiler screen that shows a lot of Call objects linked to tomcat's threads through ThreadLocalS (after stopping the web app, of course), but I do not know how to attach a file in JIRA (I'm a newbie to JIRA system). Also, I do't want to make public the name of the profiler on this list (it's a commercial one, I've used an evaluation version), as I don't want to be acused of making publicity. If you are interested, I can send you the screenshot (and profiler name) by email. > Using ThreadLocal Call objects in a servlet memory leak both on client and > server side > -------------------------------------------------------------------------------------- > > Key: AXIS-935 > URL: http://issues.apache.org/jira/browse/AXIS-935 > Project: Axis > Type: Bug > Components: Basic Architecture > Versions: 1.1rc2 > Environment: Operating System: All > Platform: All > Reporter: Jennifer Jackson > > I discovered using Axis in tomcat causes a memory leak. > It seems using threadlocal in the classes causes a memory leak for each Call > that is created. Threadlocal sticks around until the calling thread dies, > and > since tomcat keeps threads alive to answer new calls, the threadlocal data > never goes away. The Call object gets stuck in the threadlocal data, which > contains the entire soap response and all objects. This is a BIG memory > leak. > I initially cleared it by forcing all Call objects to clean their member vars > after I was done with a call, then I realized the source was from the thread > local class. Here is some info I found about threadlocal: > This is stated in the Sun Javadocs for ThreadLocal: > Each thread holds an implicit reference to its copy of a > ThreadLocal as long as the thread is alive and the > ThreadLocal object is accessible; after a thread goes > away, all of its copies of ThreadLocal variables are > subject to garbage collection (unless other references > to these copies exist). > So, this means that ANY APPLICATION that uses PreparedStatements in a thread > that 1) either does a lot of PreparedStatements or 2) never dies (i.e., a > main thread) will ALWAYS eventually have an out of memory error. Simply put, > this is a MEMORY LEAK. I imagine that the leak is very small, the > ThreadLocal object only contains one member variable, maybe 64 bytes or less > (depending on the VM implementation). So, our 60,000 PreparedStatements of 2 > ThreadLocals each times 64 bytes (my wild guess) is 7.5MB. > Ideas? I've never used threadlocal myself so this is new to me. -- 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
