[
https://issues.apache.org/jira/browse/GEODE-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham resolved GEODE-8988.
---------------------------------
Resolution: Won't Fix
This code has been in the product for a long time. We did a little
investigation and find no evidence to support the assertion that there is a
performance problem here. If somebody can find evidence of a high-priority
performance problem here then we will fix it then.
> Optimize GMSMembership.getMembersNotShuttingDown() to return a static list of
> members
> -------------------------------------------------------------------------------------
>
> Key: GEODE-8988
> URL: https://issues.apache.org/jira/browse/GEODE-8988
> Project: Geode
> Issue Type: Improvement
> Components: membership
> Affects Versions: 1.15.0
> Reporter: Kamilla Aslami
> Priority: Major
> Attachments: call_counting.png
>
>
> In GEODE-7245 [PR
> review|https://github.com/apache/geode/pull/6037#discussion_r582368198], Jake
> suggested this change in GMSMembership.getMembersNotShuttingDown() method:
> If the shutdownMembers list isn't changing frequently, like every ms, then
> repeatedly recreating the same set is just adding pressure to the GC and CPU
> time all while under a synchronized lock for no real gain. I assume this
> shutdownMembers list is updated with the member id of the member that has
> said it is or has gone down, which isn't a frequent event in production.
> Seems like we should be optimizing this method to be returning a rather
> static list of members known not to be shutting down even if that means the
> infrequent setting of a shutting down member takes a bit more time to handle,
> by copying lists and invalidating or updating the not shutdown servers list.
>
> The fix for GEODE-7245 replaces synchronized blocks around shutdownMembers
> list with read/write locks. In GMSMembership.getMembersNotShuttingDown()
> method, shutdownMembers list is used to create a new collection of members
> not shutting down. This method is called for every p2p message sent, so the
> proposed change is a reasonable optimization.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)