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.
