axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject AXIS-Java/C++ server side performance / memory footprint
Date Thu, 03 Jun 2004 17:58:41 GMT
Davanum Srinivas wrote:

>You need to turn streaming on the client-side as well. see
>samples/perf in latest cvs.
>
>        binding._setProperty(org.apache.axis.client.Call.STREAMING_PROPERTY,
>Boolean.TRUE);
>  
>
i am interested in testing server side performance (as server side is 
typically the bottleneck) so i use the same client to access all 
services to measure only factors that are effecting server side 
performance (CPU, memory footprint, scalability).

hopefully soon i will have AXIS-C++ numbers - i am really close now to 
get them after few weeks of struggling with C++ (Java configuration and 
build tools are much easier even when dealing with JAR hell  ...)

so it should be interesting to see how AXIS-Java and AXIS-C++ compare.

however i am also *very* interested in very long running web services so 
Peter post about _huge_ memory leaks that are easily reproducible looked 
very interesting  to me :) is it a property of data graph he send or is 
it just a bug ...

thanks,

alek

>-- dims
>
>On Thu, 03 Jun 2004 12:27:18 -0500, Aleksander Slominski
><aslom@cs.indiana.edu> 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
>>
>>
>>    
>>


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


Mime
View raw message