You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Darrel Schneider (JIRA)" <ji...@apache.org> on 2019/05/01 23:01:00 UTC
[jira] [Assigned] (GEODE-6730)
checkSameSenderIdsAvailableOnAllNodes performance could be improved
[ https://issues.apache.org/jira/browse/GEODE-6730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Darrel Schneider reassigned GEODE-6730:
---------------------------------------
Assignee: Darrel Schneider
> checkSameSenderIdsAvailableOnAllNodes performance could be improved
> -------------------------------------------------------------------
>
> Key: GEODE-6730
> URL: https://issues.apache.org/jira/browse/GEODE-6730
> Project: Geode
> Issue Type: Improvement
> Components: core
> Reporter: Darrel Schneider
> Assignee: Darrel Schneider
> Priority: Major
> Labels: performance
>
> While working on GEODE-6689 I realized that for every write operation on a distributed region we call checkSameSenderIdsAvailableOnAllNodes. This method ends up (after GEODE-6689 is fixed) iterating over all the advisors profiles twice. For each profile it calls set equals.
> So for larger clusters, this method will need to do more work (one profile for each cluster member).
> Also if you have gateway senders or async queue ids then you take another performance hit because you end up calling HashSet.equals which iterates over one of the sets checking that each item is in the other.
> The sad thing is that we do this work on every write operation. We should be only doing it when the profile information (in this case gatewaySenderIds and asyncEventQueueIds) changes. The advisor has this knowledge. Just be aware that the advisor does not store a profile for the local member (you can call DistributionAdvisee.getProfile but be aware that the current implementations of that method create a new profile each time it is called). Also you probably will still need to do the check on each write operation but that check could be as simple as checking a boolean on the advisor that it maintains if its gateways and asyncEventQueues are equal. I think the current lazy check may be because as you add a gateway or asyncEventQueue at runtime you can only do it one member at a time so while it is being added your cluster will have a window of time that it is inconsistent. But as long as you don't do a write operation in that window then you should not get any errors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)