[
https://issues.apache.org/jira/browse/CAMEL-12969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bob Paulin updated CAMEL-12969:
-------------------------------
Attachment: karafCamelContextStop.PNG
> 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.18.0, 2.19.0, 2.20.0, 2.21.0, 2.22.0, 2.23.0
> Environment: Java 10
> Karaf 4.2.1
> Camel 2.22.0
> Reporter: Bob Paulin
> Priority: Major
> Attachments: ServiceReferenceQueueLeak.PNG,
> ServiceReferenceQueuePostContextStop.PNG,
> ServiceReferenceQueuePreContextStop.PNG, karafCamelContextStop.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.
> !ServiceReferenceQueueLeak.PNG! .
>
> 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.
> See serviceReferenceQueue pre context stop
>
> See serviceReferenceQueue post context stop (still contain objects)
>
> 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)
