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)
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).
Thanks
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
