axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Schwell (JIRA)" <>
Subject [jira] Commented: (AXIS-935) Using ThreadLocal Call objects in a servlet memory leak both on client and server side
Date Mon, 28 Mar 2005 13:58:18 GMT
     [ ]
Steven Schwell commented on AXIS-935:

Yes, I confirm that 1.2RC3 is still leaking memory in a Thread-pooled server. Best guess is
that it is related to use of ThreadLocals which are not released when a Thread is put back
in the pool. 

Wish Java had a way to clear all ThreadLocals of a Thread. Failing that we need to provide
a way to clear all ThreadLocals set by Axis. Alternatively, abandon use of ThreadLocals.

This is high priority since it is a true memory leak. This bug should be reopened. Anyone
know how to do that?

> Using ThreadLocal Call objects in a servlet memory leak both on client and server side
> --------------------------------------------------------------------------------------
>          Key: AXIS-935
>          URL:
>      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:
If you want more information on JIRA, or have a bug to report see:

View raw message