axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Friedman" <matt.fried...@gmail.com>
Subject Re: When do cleanup functions need to be called?
Date Tue, 23 Sep 2008 01:39:34 GMT
Hi, was this issue fixed or resolved? I am running our service in
JProbe and we are having the identical memory leak issues as described
in this email chain. After roughly 900 requests the garbage collector
goes to 100% and out of memory occurs.

Over half the heap is full with instances related to:
edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap.*
which is tied to the Axis2 implementation. We don't use edu.emory.* at
all.

We are running Axis2 v1.4. We're going to try a more recent release or
the svn nightly build.

Any thoughts or recommendations?

If you need any further information please let me know.

Many thanks,
Matt Friedman.



2008/7/31 Amila Suriarachchi <amilasuriarachchi@gmail.com>:
>
>
> On Wed, Jul 30, 2008 at 11:08 PM, David Rees <drees76@gmail.com> wrote:
>>
>> On Wed, Jul 30, 2008 at 4:22 AM, Amila Suriarachchi
>> <amilasuriarachchi@gmail.com> wrote:
>> > On Wed, Jul 30, 2008 at 2:15 PM, David Rees <drees76@gmail.com> wrote:
>> >
>> > well see this code,
>> >
>> > public static void clientCall1() {
>> >  MyServiceStub stub = new MyServiceStub("http://example.com/myservice");
>> >  ClientCall1 req = new ClientCall1();
>> >  ClientCall1Response res = stub.clientCall1(req);
>> >  // Need to call this when calling using this function in a web service
>> >  // Otherwise huge resource leak occurs
>> >  stub._getServiceClient().
>> > cleanup();
>> >  }
>> > }
>> >
>> > After this method call this class should be garbage collected. since
>> > stub
>> > does not have any reference after that.
>>
>> Right - but I'm not having a problem with Stubs being leaked. Here's a
>> count of various interesting classes (I've skipped some of the Java
>> core classes for brevity) of which there are a high number of
>> instances when the heap runs out of space (using a 32mb heap):
>>
>> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$Segment
>> 177,023, 17% heap
>>
>> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$HashEntry[]
>> 177,023, 6% heap
>>
>> edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLock$NonfairSync
>> 177,023, 8% heap
>> java.util.HashMap$Entry[] 37926, 8% heap
>> java.util.HashMap 36789, 4% heap
>> java.util.HashMap$Entry 28853, 2% heap
>> java.util.ArrayList 13698, 1% heap
>> org.apache.axis2.description.ParameterIncludeImpl 11099, 0% heap
>> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap 11064, 1%
>> heap
>> org.apache.axis2.description.PolicySubject 11063, 0% heap
>> org.apache.axis2.engine.Phase 7905, 0% heap
>> org.apache.axis2.description.AxisBindingMessage 4668, 1% heap
>> org.apache.axis2.description.AxisMessage 3168
>>
>> So it's pretty easy to see where the majority of the heap is being
>> used, about half the heap is being used by the ConcurrentHashMap and
>> HashMaps.
>>
>> Tracing a ConcurrentHashMap$Segment to it's root goes like this (class
>> name w/variable name):
>>
>> ConcurrentHashMap$Segment
>> ConcurrentHashMap$Segment[]
>> ConcurrentHashMap (children)
>> OutInAxisOperation
>> HashMap$Entry
>> HashMap$Entry[]
>> HashMap operationsAliasesMap
>> AxisService
>> HashMap$Entry (value)
>> HashMap$Entry[]
>> HashMap (allEndpoints)
>
> this is the place this issue was fixed.
>>
>> AxisConfiguration (axisConfiguration)
>> AxisServlet
>>
>> Hopefully that provides some insight as to where reference chain is going.
>>
>> Now, after more trial and error, I believe that I've figured out a way
>> to keep it from leaking (the service has been running overnight now
>> with a 32MB heap and it has not gone OOM yet):
>>
>> 1. Use Axis2 1.4.1 RC1
>> 2. Create a pool of stubs to use so that only one thread uses a Stub at a
>> time.
>>
>> #2 I tried after a lot of googling and mail archive searches where I
>> found a post that indicated that the creation of and use of Stubs may
>> not be thread safe. I don't know enough about the internals of axis2
>> as to why this may be an issue, but hopefully it can point the
>> developers in the right direction (still haven't been able to create a
>> small test case).
>
> then we can have a better look.
>
> thanks,
> Amila.
>>
>>
>> Thanks
>>
>> -Dave
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>



-- 
-- Matt Friedman

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Mime
View raw message