[jboss-jira] [JBoss JIRA] (WFLY-8939) Clustering creating a large number of ServiceName instances

[Paul Ferraro (Jira)]

     [ https://issues.jboss.org/browse/WFLY-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-8939:
-------------------------------
    Priority: Minor  (was: Major)


> Clustering creating a large number of ServiceName instances
> -----------------------------------------------------------
>
>                 Key: WFLY-8939
>                 URL: https://issues.jboss.org/browse/WFLY-8939
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Paul Ferraro
>            Priority: Minor
>         Attachments: servicenameparse.txt
>
>
> A downside of the shift to capability-driven service wiring has been a significant increase in memory use related to ServiceName instances. A ServiceName is basically a linked list of a string wrapper objects, with the wrapper objects sharable between lists. In the old way of hand creating ServiceNames the wrapper objects would typically be shared widely since a new name would be created by appending a new wrapper to the last element in an existing chain.
> With capabilities, this breaks down as ServiceNames are being created by parsing a dot-separated string. Names created that way no longer share elements and multiple instances of strings like "org" and "wildlfy" end up being kept in memory.
> https://issues.jboss.org/browse/WFCORE-2895 is about improving this in the kernel. But analyzing the result of my effort there didn't show as big of an impact as I expected. Investigating why, I see a lot of uses of ServiceName.parse in the clustering code, which will have the same effect. I'll attach the results of "git grep ServiceName.parse" against the full WildFly code base.
> I don't know how easily this can be resolved. The kernel may need to provide a capability-name to ServiceName utility that can do optimizations.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)