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
