axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
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:50 GMT
Peter,

If i can recreate this on my machine, i promise to fix it ASAP :) Just
create a jira bug (http://issues.apache.org/jira) with the sample code
and instructions.

-- dims

On Thu, 3 Jun 2004 10:18:45 -0700, Peter Molettiere
<pietro@axonstudios.net> 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.
> 
> Hopefully, we'll have more info in the next couple days.
> 
> --Peter
> 
> 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
> 
>

Mime
View raw message