Hi Ruwan, On Mon, Nov 30, 2009 at 7:18 AM, Ruwan Linton <[email protected]> wrote:
> AFAIK, Abdera creates a new instance of the HTTPClient when ever it > needs to do a HTTP call and doesn't care about the tear down properly. > That should be the root cause of the issue. > I believe it could be the cause to this as well. Yesterday I fixed an issue in our Abdera branch, which now makes it release all connections as soon as it finishes executing the desired operation. I will try out the Remote Registry and see whether this solves this issue. Thanks, Senaka. > > Thanks, > Ruwan > > Senaka Fernando wrote: > > > > > > On Sun, Nov 29, 2009 at 5:50 PM, Sanjiva Weerawarana <[email protected] > > <mailto:[email protected]>> wrote: > > > > Senaka, are you using an older version of Carbon? > > > > > > No, I tried this on the trunk. > > > > > > In the new code we don't hit Abdera in the normal execution path > > right? > > > > > > Yes, we don't for RemoteRegistry. But we use Abdera for our atom > > feeds. But, IMO, this is not something on our critical path. > > > > > > In any case, if there's a leak we need to fix it ... > > > > > > I believe that this has something to do with how Abdera handles the > > HTTPClient. Abdera had few issues that we fixed recently, and I feel > > that it might be due to some sloppy code in Abdera (waiting to be > > fixed :-).. ), since Axis2 doesn't seems to be affected at all. Will > > try to get this sorted. > > > > Thanks, > > Senaka. > > > > > > Sanjiva. > > > > On Sun, Nov 29, 2009 at 3:57 PM, Senaka Fernando <[email protected] > > <mailto:[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] <mailto:[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> > > <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] <mailto:[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] <mailto:[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] <mailto:[email protected]> > > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Carbon-dev mailing list > > [email protected] > > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > > > > -- > Ruwan Linton > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb > WSO2 <http://wso2.org/esb%0AWSO2> Inc.; http://wso2.org > email: [email protected]; cell: +94 77 341 3097 > blog: http://blog.ruwan.org > > > > _______________________________________________ > Carbon-dev mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >
_______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
