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 <[EMAIL PROTECTED]>:
- Hide quoted text -
>
>
> On Wed, Jul 30, 2008 at 11:08 PM, David Rees <[EMAIL PROTECTED]> wrote:
>>
>> On Wed, Jul 30, 2008 at 4:22 AM, Amila Suriarachchi
>> <[EMAIL PROTECTED]> wrote:
>> > On Wed, Jul 30, 2008 at 2:15 PM, David Rees <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
2008/9/23 Matt Friedman <[EMAIL PROTECTED]>:
> 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 <[EMAIL PROTECTED]>:
>> 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 <[EMAIL PROTECTED]>:
>>> On Mon, Sep 22, 2008 at 6:39 PM, Matt Friedman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>>
>> --
>> -- Matt Friedman
>>
>
>
>
> --
> -- Matt Friedman
>
--
-- Matt Friedman
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
