DO NOT REPLY [Bug 21186] New: - Using ThreadLocal Call objects in a servlet memory leak both on client and server side

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21186>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21186

Using ThreadLocal Call objects in a servlet memory leak both on client and server side

           Summary: Using ThreadLocal Call objects in a servlet memory leak
                    both on client and server side
           Product: Axis
           Version: 1.1rc2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Basic Architecture
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: jen.jackson@cox.com


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.