Senaka, are you using an older version of Carbon? In the new code we don't hit Abdera in the normal execution path right?
In any case, if there's a leak we need to fix it ... Sanjiva. On Sun, Nov 29, 2009 at 3:57 PM, Senaka Fernando <[email protected]> wrote: > Hi again, > > Debugging after sometime revealed that there is some level of Garbage > Collection happening (for 10-15 new objects made, only 5-6 were persisted, > and the others were gone). But, the total number of items kept increasing. > Sometimes this might be due to way in which Abdera uses the HTTPClient as > well. There didn't seem to be any effect wrt Axis2 (looks like it is handled > well). Therefore, this doesn't seem to be a major problem. > > Thanks, > Senaka. > > > On Sun, Nov 29, 2009 at 2:27 PM, Senaka Fernando <[email protected]> wrote: > >> Hi all, >> >> While working on a fix to issue, [1], I happened to review the code of >> [2]. In [2], if you search for ALL_CONNECTION_MANAGERS, you can see that you >> only put objects into it, and never remove. However, ALL_CONNECTION_MANAGERS >> is a WeakHashMap, [3], and I believe the expectation here is that the key >> will be removed once there are no strong references to it. Interestingly, >> the objects stored in this WeakHashMap are of type >> MultiThreadedHttpConnectionManager. And, each >> MultiThreadedHttpConnectionManager has a non-static inner class >> ConnectionPool which maintains a strong reference to the parent, [4-5]. >> Also, the MultiThreadedHttpConnectionManager contains a reference to the >> ConnectionPool. Thus, even after GC, the MultiThreadedHttpConnectionManager >> contains a valid circular reference to itself. And, AFAIU, the purpose of >> having a WeakHashMap doesn't seem to worthwhile in this scenario. >> >> Thus, (according to my personal belief - please correct me if I'm wrong >> here) in theory and by debugging (I only have kept the server running for >> about 3-4 hours, and the map doesn't seem to shrink. I manually called >> System.gc() which had no effect.) into the code, I discovered that the >> ALL_CONNECTION_MANAGERS map is growing per each new >> MultiThreadedHttpConnectionManager being created. >> >> Our older atom-based remote registry, [6], creates a new AbderaClient, >> [7], per each registry operation, which in return creates a >> MultiThreadedHttpConnectionManager. Thus, even during halfway of startup, >> the ALL_CONNECTION_MANAGERS map has over 100 stale references stored in it. >> And, the number keeps increasing per registry call made. >> >> Axis2 however allows users to reuse the >> MultiThreadedHttpConnectionManager, which prevents creating new instances, >> but I wonder whether this is being practiced. >> >> Therefore, I wonder whether this could be a potential memory leak that >> would affect Carbon based products? >> >> [1] https://wso2.org/jira/browse/CARBON-4444 >> [2] >> http://hc.apache.org/httpclient-3.x/xref/org/apache/commons/httpclient/MultiThreadedHttpConnectionManager.html >> [3] http://java.sun.com/j2se/1.5.0/docs/api/java/util/WeakHashMap.html >> [4] >> http://www.codepoet.org/~markw/weber/java/ch6/notes.html<http://www.codepoet.org/%7Emarkw/weber/java/ch6/notes.html> >> [5] >> http://www.coderfriendly.com/2009/06/27/inner-classes-static-and-non-static/ >> [6] >> https://svn.wso2.org/repos/wso2/trunk/carbon/org.wso2.carbon.registry.core/src/main/java/org/wso2/carbon/registry/app/RemoteRegistry.java >> [7] >> http://svn.apache.org/repos/asf/abdera/java/trunk/client/src/main/java/org/apache/abdera/protocol/client/AbderaClient.java >> >> Thanks, >> Senaka. >> > > > _______________________________________________ > Carbon-dev mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- Sanjiva Weerawarana, Ph.D. Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ email: [email protected]; phone: +1 408 754 7388 x51726; cell: +94 77 787 6880 blog: http://sanjiva.weerawarana.org/ The Open Source SOA Company
_______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
