You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Matt Friedman <ma...@gmail.com> on 2008/09/23 18:15:27 UTC
Axis 2 Memory Leak when Client is instantiated within Service - pertains to edu.emory...ConcurrentHashMap -> WAS: Re: When do cleanup functions need to be called?
Hi,
I'm sorry for the re-post, but I was discussing this thread with a
co-worker and we postulated that the title of the existing post (Re:
When do cleanup functions need to be called?), didn't represent what
this thread is actually about.
I was afraid the importance of the thread might be missed, as the old
title no longer applies.
Hopefully, this isn't inappropriate. Sorry if I've annoyed anyone.
So, renamed more appropriately, here is the thread...
Many thanks,
Matt Friedman.
2008/9/23 Matt Friedman <ma...@gmail.com>:
> Hi David,
>
> Thanks very much for this.
>
> When you say: "Try 1.4.1. It's much better than 1.4 with this
> particular memory leak.", I take it you mean it is partially fixed,
> but not entirely fixed in 1.4.1. Is that correct?
>
> Did your pool of stubs continue to work for you?
>
> My goal is to completely eliminate any mem leaks from our app.
>
> Thanks,
> Matt.
>
>
> 2008/9/23 David Rees <dr...@gmail.com>:
>> On Mon, Sep 22, 2008 at 6:39 PM, Matt Friedman <ma...@gmail.com> wrote:
>>> 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.
>>
>> Try 1.4.1. It's much better than 1.4 with this particular memory leak.
>> If your access to the stub constructor isn't synchronized, you may
>> need to serialize access to stub constructors as well.
>>
>> -Dave
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
>
> --
> -- Matt Friedman
>
--
-- Matt Friedman
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Axis 2 Memory Leak when Client is instantiated within Service -
pertains to edu.emory...ConcurrentHashMap -> WAS: Re: When do cleanup
functions need to be called?
Posted by jijisv <ji...@gmail.com>.
Matt,
did you get this issue fixed?
I am facing the same error in the project I am working on. I am using Axis
1.4.1.
Appreciate your help.
Regards
Jiji
Matt Friedman wrote:
>
> Hi,
>
> I'm sorry for the re-post, but I was discussing this thread with a
> co-worker and we postulated that the title of the existing post (Re:
> When do cleanup functions need to be called?), didn't represent what
> this thread is actually about.
>
> I was afraid the importance of the thread might be missed, as the old
> title no longer applies.
>
> Hopefully, this isn't inappropriate. Sorry if I've annoyed anyone.
>
> So, renamed more appropriately, here is the thread...
>
> Many thanks,
> Matt Friedman.
>
>
> 2008/9/23 Matt Friedman <ma...@gmail.com>:
>> Hi David,
>>
>> Thanks very much for this.
>>
>> When you say: "Try 1.4.1. It's much better than 1.4 with this
>> particular memory leak.", I take it you mean it is partially fixed,
>> but not entirely fixed in 1.4.1. Is that correct?
>>
>> Did your pool of stubs continue to work for you?
>>
>> My goal is to completely eliminate any mem leaks from our app.
>>
>> Thanks,
>> Matt.
>>
>>
>> 2008/9/23 David Rees <dr...@gmail.com>:
>>> On Mon, Sep 22, 2008 at 6:39 PM, Matt Friedman <ma...@gmail.com>
>>> wrote:
>>>> 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.
>>>
>>> Try 1.4.1. It's much better than 1.4 with this particular memory leak.
>>> If your access to the stub constructor isn't synchronized, you may
>>> need to serialize access to stub constructors as well.
>>>
>>> -Dave
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>>
>>
>>
>>
>> --
>> -- Matt Friedman
>>
>
>
>
> --
> -- Matt Friedman
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Axis-2-Memory-Leak-when-Client-is-instantiated-within-Service---pertains-to-edu.emory...ConcurrentHashMap--%3E-WAS%3A-Re%3A-When-do-cleanup-functions-need-to-be-called--tp19631299p23850641.html
Sent from the Axis - User mailing list archive at Nabble.com.
Re: Axis 2 Memory Leak when Client is instantiated within Service - pertains to edu.emory...ConcurrentHashMap -> WAS: Re: When do cleanup functions need to be called?
Posted by Matt Friedman <ma...@gmail.com>.
I'm really sorry, I didn't attach the whole thread the first time.
Here are the details...
--------------------------------------
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 <am...@gmail.com>:
- Hide quoted text -
>
>
> On Wed, Jul 30, 2008 at 11:08 PM, David Rees <dr...@gmail.com> wrote:
>>
>> On Wed, Jul 30, 2008 at 4:22 AM, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> > On Wed, Jul 30, 2008 at 2:15 PM, David Rees <dr...@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.
>
2008/9/23 Matt Friedman <ma...@gmail.com>:
> Hi,
>
> I'm sorry for the re-post, but I was discussing this thread with a
> co-worker and we postulated that the title of the existing post (Re:
> When do cleanup functions need to be called?), didn't represent what
> this thread is actually about.
>
> I was afraid the importance of the thread might be missed, as the old
> title no longer applies.
>
> Hopefully, this isn't inappropriate. Sorry if I've annoyed anyone.
>
> So, renamed more appropriately, here is the thread...
>
> Many thanks,
> Matt Friedman.
>
>
> 2008/9/23 Matt Friedman <ma...@gmail.com>:
>> Hi David,
>>
>> Thanks very much for this.
>>
>> When you say: "Try 1.4.1. It's much better than 1.4 with this
>> particular memory leak.", I take it you mean it is partially fixed,
>> but not entirely fixed in 1.4.1. Is that correct?
>>
>> Did your pool of stubs continue to work for you?
>>
>> My goal is to completely eliminate any mem leaks from our app.
>>
>> Thanks,
>> Matt.
>>
>>
>> 2008/9/23 David Rees <dr...@gmail.com>:
>>> On Mon, Sep 22, 2008 at 6:39 PM, Matt Friedman <ma...@gmail.com> wrote:
>>>> 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.
>>>
>>> Try 1.4.1. It's much better than 1.4 with this particular memory leak.
>>> If your access to the stub constructor isn't synchronized, you may
>>> need to serialize access to stub constructors as well.
>>>
>>> -Dave
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>>
>>
>>
>>
>> --
>> -- Matt Friedman
>>
>
>
>
> --
> -- Matt Friedman
>
--
-- Matt Friedman
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org