[jira] [Commented] (FELIX-5987) Slow ServiceComponentRuntime with delivering ServiceReferenceDTOs

["Carsten Ziegeler (JIRA)" <ji...@apache.org>]

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

Carsten Ziegeler commented on FELIX-5987:
-----------------------------------------

The attached patch brings back the old performance by using a simple cache in the runtime service. Entries are dropped from the cache on bundle or service events for a bundle.
The only downside is that the cache holds the information now forever (for a stable system); I guess it would make sense to simply drop the cache after some time.

> Slow ServiceComponentRuntime with delivering ServiceReferenceDTOs
> -----------------------------------------------------------------
>
>                 Key: FELIX-5987
>                 URL: https://issues.apache.org/jira/browse/FELIX-5987
>             Project: Felix
>          Issue Type: Improvement
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-2.1.8, scr-2.1.10, scr-2.1.12, scr-2.1.14
>            Reporter: Carsten Ziegeler
>            Priority: Major
>             Fix For: scr-2.1.16
>
>         Attachments: patch.txt
>
>
> Since the 2.1.8 we switched the DTO generation in the runtime service to use the ServiceReferenceDTO from the framework instead of duplicating that logic. However, as the framework only provides a method to get all ServiceReferences for a bundle, this results in a huge drop in performance within the DTO generation. This gets even worse if a set of DTOs is to be generated, as each time the framework is asked for all DTOs of a bundle.
> As there is no other way to get the ServiceReferenceDTO from the framework, the service runtime should probably cache the information; 



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