[jira] Resolved: (AXIS-935) Using ThreadLocal Call objects in a servlet memory leak both on client and server side

["Davanum Srinivas (JIRA)" <ax...@ws.apache.org>]

     [ http://issues.apache.org/jira/browse/AXIS-935?page=all ]
     
Davanum Srinivas resolved AXIS-935:
-----------------------------------

    Resolution: Fixed

removed threadlocals

> 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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira