[ 
https://issues.apache.org/jira/browse/FELIX-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701909#comment-16701909
 ] 

Pierre De Rop commented on FELIX-5990:
--------------------------------------

Attached  dm.memoryleak.tgz, which is a simple project that is reproducing the 
issue.

> DM ServiceTracker memory leak
> -----------------------------
>
>                 Key: FELIX-5990
>                 URL: https://issues.apache.org/jira/browse/FELIX-5990
>             Project: Felix
>          Issue Type: Bug
>          Components: Dependency Manager
>    Affects Versions: dependencymanager-3.0.0
>            Reporter: Pierre De Rop
>            Assignee: Pierre De Rop
>            Priority: Major
>         Attachments: dm.memoryleak.tgz, oom.png
>
>
> We have an old memory leak that comes from dependency manager 3.0.0 version, 
> where the dm ServiceTracker does not remove the Set used to register highest 
> tracked services when an optional ServiceDependency becomes unavailable.
> Here is the old code where the memory leak happens, in 
> org.apache.felix.dm.tracker.ServiceTracker.java:
>  
> {code:java}
> private void addHighestTrackedCache(ServiceReference reference) {
>     Long serviceId = ServiceUtil.getServiceIdObject(reference);
>     TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
>     if (services == null) {
>     services = new TreeSet();
>     m_highestTrackedCache.put(serviceId, services);
>     }
>     services.add(reference);
> }
> private void removeHighestTrackedCache(ServiceReference reference) {
>     Long serviceId = ServiceUtil.getServiceIdObject(reference);
>     TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
>     if (services != null) {
>         services.remove(reference);
>     }
> }
> {code}
> So, the removeHighestTrackedCache does not remove the TreeSet from the 
> m_highestTrackedCache when it becomes empty. 
> So, the memory leak happens in the following situation: you have a Consumer 
> component which has an optional dependency on a Provider, and the Provider 
> service disappears and reappears a huge number of time.
> The memory can grow slowly, but may lead to an OOM in case the framework is 
> run for a very long time and if the Provider service is 
> registered/unregistered a lot of time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to