axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: [jira] Commented: (AXIS-935) Using ThreadLocal Call objects in a servlet memory leak both on client and server side
Date Thu, 03 Jun 2004 17:27:18 GMT

please post more details how to reproduce the memory leak and i will add 
to what i have for WS/SOAP performance tests at:



Peter Molettiere wrote:

> We're currently looking into a massive memory leak in axis, that no 
> one  here seems willing to admit. We're close to having a minimal test 
> case  which demonstrates the leak we're seeing. I don't think it's the 
> same  one you're seeing however, as our leak happens 1) when the 
> server is  sitting doing nothing (but only after axis has been 
> loaded), and 2)  every time we serialize a large message.  The 
> suggestions on the list  about switching to using attachments doesn't 
> fix the leak sadly. And  setting a larger heap size only delays the 
> inevitable Out Of Memory  Exception.
> From our testing, it looks like it takes on the order of 700MB to  
> serialize a 30MB java object graph into a 3MB SOAP stream.
> I've posted about this before, but no one has responded. Hopefully 
> when  we post the test case someone will actually take a look at it. 
> There  are other threads with test cases which currently have "we're 
> looking  at this now" as the only response, but as they are all pretty 
> old  threads, my guess is that this problem either isn't believed or 
> is  being swept under the carpet. Maybe we're the only people using 
> axis  for large messages.

> --
> On Jun 3, 2004, at 9:38 AM, wrote:
>> The following comment has been added to this issue:
>>      Author: Jennifer Jackson
>>     Created: Thu, 3 Jun 2004 9:37 AM
>>        Body:
>> Has anyone looked into this?  I haven't used Axis because of this  
>> problem and doing a quick search it seems others have come across  
>> memory leaks also.  I narrowed it down to the Call object not 
>> cleaning  out its member vars (the whole Deserialization process).  
>> If you do  that the only thing stuck in memory is the call object 
>> since its part  of the ThreadLocal object.
>> ---------------------------------------------------------------------
>> View this comment:
>> page=comments#action_35890
>> ---------------------------------------------------------------------
>> View the issue:
>> Here is an overview of the issue:
>> ---------------------------------------------------------------------
>>         Key: AXIS-935
>>     Summary: Using ThreadLocal Call objects in a servlet memory leak  
>> both on client and server side
>>        Type: Bug
>>      Status: Open
>>     Project: Axis
>>  Components:
>>              Basic Architecture
>>    Versions:
>>              1.1rc2
>>    Assignee: Axis Developers Mailing List
>>    Reporter: Jennifer Jackson
>>     Created: Mon, 30 Jun 2003 12:12 PM
>>     Updated: Thu, 3 Jun 2004 9:37 AM
>> Environment: Operating System: All
>> Platform: All
>> Description:
>> 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:

The best way to predict the future is to invent it - Alan Kay

View raw message