[
https://issues.apache.org/jira/browse/CAMEL-12969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bob Paulin updated CAMEL-12969:
-------------------------------
Description:
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.
was:
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.
> 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,
> ServiceReferenceQueuePreContextStop.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)
