[
https://issues.apache.org/jira/browse/FELIX-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated FELIX-4424:
-----------------------------------
Description:
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
was:
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
> 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)
