[ http://issues.apache.org/jira/browse/AXIS-935?page=comments#action_61735 ] Steven Schwell commented on AXIS-935: -------------------------------------
I'm not convinced that the problem is with the ThreadLocal previousCall. It could be with any of the other uses of ThreadLocal in Axis. This is really a general Java problem with ThreadLocals and Thread pooling. If we cannot get away without using ThreadLocals then I think the best approach is to provide static method or methods to clear ALL ThreadLocals, similair to Service.clearCall(). > 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
