Bob Paulin created CAMEL-12969:
----------------------------------

             Summary: camel-core-osgi: Slow Memory Leak in OsgiServiceRegistry
                 Key: CAMEL-12969
                 URL: https://issues.apache.org/jira/browse/CAMEL-12969
             Project: Camel
          Issue Type: Bug
          Components: camel-osgi
    Affects Versions: 2.23.0, 2.22.0, 2.21.0, 2.20.0, 2.19.0, 2.18.0
         Environment: Java 10

Karaf 4.2.1

Camel 2.22.0
            Reporter: Bob Paulin
         Attachments: ServiceReferenceQueueLeak.PNG

The OsgiServiceRegistry has a slow memory leak in the serviceReferenceQueue.  
Currently every time a service is looked up by any method an item is added to 
the serviceReferenceQueue.  This is required because of OSGi ServiceReference 
counting.  However left unchecked the system just continues to add 
ConcurrentLinkedQueue$Node objects until memory is exhausted. 

 

There is also a second problem with how the registry is being managed within 
the OsgiDefaultCamelContext.  OsgiServiceRegistry is currently extends 
LifecycleStrategySupport which is suppose to unload the serviceReferenceQueue 
onContextStop.  However the registry is never getting added to the CamelContext 
to manage the Lifecycle because the overridden createRegistry method in 
OsgiDefaultCamelContext is not being called.  This is because the registry is 
being set in the constructor of OsgiDefaultCamelContext with
{code:java}
super(registry);{code}
this calls the DefaultCamelContext implementation of createRegistry which does 
not add the registry to lifecyclemanagement since
{code:java}
OsgiCamelContextHelper.wrapRegistry(this, registry, bundleContext);{code}
is never called.

 

Both issues would have existed for some time but may have gone unnoticed 
because the leak was so slow (ConcurrentLinkedQueue$Node takes up very little 
memory).  It appears the removal of the cache in 
https://issues.apache.org/jira/browse/CAMEL-9631 makes the leak occur more 
quickly. 

 

I have a patch that involves reintroducing the cache but with an invalidation 
strategy using the OSGi ServiceListener that leverages a single clean up thread 
to remain non-blocking.  I'm working on an upstream adaptation and will post a 
PR for community review.

 

 



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

Reply via email to