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
