[jira] [Work logged] (CAMEL-12969) camel-core-osgi: Slow Memory Leak in OsgiServiceRegistry

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-12969?focusedWorklogId=179803&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-179803 ]

ASF GitHub Bot logged work on CAMEL-12969:
------------------------------------------

                Author: ASF GitHub Bot
            Created on: 30/Dec/18 16:43
            Start Date: 30/Dec/18 16:43
    Worklog Time Spent: 10m 
      Work Description: bobpaulin commented on pull request #2695: CAMEL-12969 : Map based Service Usage counting to remove memory leak
URL: https://github.com/apache/camel/pull/2695
 
 
   This showed comparable performance to using the service cache and thread in my previous PR.  The leak does not occur since the Queue has been replaced with a map of AtomicLongs to count usage.
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

            Worklog Id:     (was: 179803)
            Time Spent: 10m
    Remaining Estimate: 0h

> 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
>             Fix For: 2.22.3, 2.24.0, 2.23.1
>
>         Attachments: ServiceReferenceQueueLeak.PNG, ServiceReferenceQueuePostContextStop.PNG, ServiceReferenceQueuePreContextStop.PNG, karafCamelContextStop.PNG
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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
>   !ServiceReferenceQueuePreContextStop.PNG!
> !karafCamelContextStop.PNG!
> See serviceReferenceQueue   post context stop (still contain objects)
>   !ServiceReferenceQueuePostContextStop.PNG!
> 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)