[ http://issues.apache.org/jira/browse/AXIS-935?page=comments#action_60974 ] Guillaume Sauthier commented on AXIS-935: -----------------------------------------
Can you confirm this in Axis 1.2RC3 ? > 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
