axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Molettiere <pie...@axonstudios.net>
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:55:22 GMT

As soon as we have the test case properly packaged, we'll post it to 
jira and here.

--Peter

On Jun 3, 2004, at 10:27 AM, Aleksander Slominski wrote:

> Peter,
>
> please post more details how to reproduce the memory leak and i will 
> add to what i have for WS/SOAP performance tests at: 
> http://www.extreme.indiana.edu/~aslom/bnp/wsperf/
>
> thanks,
>
> alek
>
> 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, jira@apache.org 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:
>>>    http://issues.apache.org/jira/browse/AXIS-935? 
>>> page=comments#action_35890
>>>
>>> ---------------------------------------------------------------------
>>> View the issue:
>>>   http://issues.apache.org/jira/browse/AXIS-935
>>>
>>> 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.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> JIRA INFORMATION:
>>> 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
>>
>>
>
>
> -- 
> The best way to predict the future is to invent it - Alan Kay


Mime
View raw message