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.
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> > [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 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
