[
https://issues.apache.org/jira/browse/FELIX-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896573#comment-13896573
]
Felix Meschberger commented on FELIX-4424:
------------------------------------------
Wow ! Excellent catch, indeed !
We could use a WeakHashMap, though, instead of a regular HashMap. This way, we
can cope for this.
{noformat}
Index: ServletContextManager.java
===================================================================
--- ServletContextManager.java (Revision 1566626)
+++ ServletContextManager.java (Arbeitskopie)
@@ -16,8 +16,8 @@
*/
package org.apache.felix.http.base.internal.context;
-import java.util.HashMap;
import java.util.Map;
+import java.util.WeakHashMap;
import javax.servlet.ServletContext;
import javax.servlet.ServletContextAttributeListener;
@@ -39,7 +39,7 @@
this.bundle = bundle;
this.context = context;
this.attributeListener = attributeListener;
- this.contextMap = new HashMap<HttpContext, ExtServletContext>();
+ this.contextMap = new WeakHashMap<HttpContext, ExtServletContext>();
this.sharedAttributes = sharedAttributes;
}
{noformat}
> ClassLoader leak in Http Service ServletContextManager
> ------------------------------------------------------
>
> Key: FELIX-4424
> URL: https://issues.apache.org/jira/browse/FELIX-4424
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
> Reporter: Chetan Mehrotra
>
> While analyzing heap dump for classloader leaks using script [1] following
> possible leak was reported
> {noformat}
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
> Following are few of the live paths found
> Live path
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
> java.util.HashMap$Entry@0x12429db50
> [Ljava.util.HashMap$Entry;@0x1238f47b0
> java.util.HashMap@0x1238f4780
>
> org.apache.felix.http.base.internal.context.ServletContextManager@0x1238f4760
> [*]
>
> org.apache.felix.http.base.internal.service.HttpServiceImpl@0x1238f45c0 [*]
>
> org.apache.felix.framework.ServiceRegistry$UsageCount@0x1238f45a8
>
> [Lorg.apache.felix.framework.ServiceRegistry$UsageCount;@0x129efb430
> java.util.HashMap$Entry@0x1235ee950
> [Ljava.util.HashMap$Entry;@0x1249e2b78
> java.util.HashMap@0x123484668
> org.apache.felix.framework.ServiceRegistry@0x12339c108
> org.apache.felix.framework.ServiceRegistrationImpl@0x126a7a3c8
> java.util.concurrent.atomic.AtomicReference@0x126a7a3b8
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x126a79ab8 [*]
> java.util.HashMap$Entry@0x126a9c3f0
> java.util.HashMap$Entry@0x1286ce7a0
> [Ljava.util.HashMap$Entry;@0x124884030
> java.util.HashMap@0x1238f1ce0
> org.apache.felix.scr.impl.ComponentRegistry@0x1236757f0 [*]
> org.apache.felix.scr.impl.BundleComponentActivator@0x127152bd0
> [*]
>
> org.apache.felix.scr.impl.config.ImmediateComponentHolder@0x127153a08 [*]
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x127154398 [*]
> org.apache.felix.scr.impl.manager.DependencyManager@0x127154720
> [*]
> {noformat}
> In our case the AuthHttpContext was being registered via the Whiteboard
> pattern. The dump shows that ServletContextManager [2] uses the HttpContext
> as key for the map however it is never removed. If our bundle would had used
> HttpService directly then internal map would have been GC upon bundle
> deactivation.
> In Felix HttpService is registered as a ServiceFactory however as all
> interactions with HttpService is done via Whiteboard bundle the HttpService
> is bound to Whiteboard bundle. So such HttpContext might remain for the
> lifetime of whiteboard bundle and hence cause classloader leak.
> [1] https://gist.github.com/chetanmeh/8860776
> [2]
> https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/context/ServletContextManager.java
> PS: The lines marked with [*] are objects which are from valid bundle and are
> maintaining hard reference to the objects from classloader which should have
> been GC
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
