[
https://issues.apache.org/jira/browse/FELIX-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396834#comment-13396834
]
Xander Uiterlinden commented on FELIX-3564:
-------------------------------------------
Fixed by a rather brute force call to FilterIndex.removeListener() for two
reasons:
- It aligns nicely with the BundleContext.removeListener() API which promises
to do nothing when a listener is passed that is not available in this
bundleContext;
- Another solution would be to explicitly keep track in the
ServiceRegistryCache of what listener is registered with which FilterIndex,
It's cheaper in memory consumption to have the indices perform an unnecessary
map.remove(). The extra processing overhead is negligible.
> Memory leak in Filterindex / ServiceRegistryCache
> -------------------------------------------------
>
> Key: FELIX-3564
> URL: https://issues.apache.org/jira/browse/FELIX-3564
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
> Affects Versions: dependencymanager-3.0.0
> Environment: Linux Mint 12, x64, Dell E6520
> Reporter: Jan Hoeve
> Assignee: Xander Uiterlinden
> Labels: memory_leak
>
> The filter indexes in the ServiceRegistryCache caches ServiceListeners for a
> faster lookup.
> However, once a ServiceListener is stored in the cache, it will never be
> released which will eventually lead to an OutOfMemoryError.
> This is caused by the implementation of
> BundleContextIntercepter#removeServiceListener.
> While debugging, it appears the cache has no filterindex for arguments
> null,null and thus leaving the listener in the cache.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
