[ http://issues.apache.org/jira/browse/AXIS-935?page=comments#action_61640 ] Tom Jordahl commented on AXIS-935: ----------------------------------
The complex nature of storing the last Call object in the service was created to achieve thread safety for the service. That is, a service could be used by more than one thread. Since the Call object is stored in the service, the thread local data is to make sure that if thread T1 gets a stub from service S and thread T2 gets a stub from S, when both T1 and T2 each call an operation, T1 can call S.getLastCall() and get the call data for T1 operation, not T2. I hope that makes sense. It is not something that the current axis comitters designed or implemented ( the implementing parties have long 'left the building'). I hope my explanation helps clear up the design goals and why it works the way it works. If its any small consolation, you can probably be assured that Axis2 wont work this way (which is not to say that we shouldn't fix Axis 1.x). > 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
