felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chetan Mehrotra (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-4424) ClassLoader leak in Http Service ServletContextManager
Date Mon, 10 Feb 2014 05:26:19 GMT

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

Mime
View raw message