[
https://issues.apache.org/jira/browse/GEODE-6730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-6730.
--------------------------------
> 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
> Fix For: 1.10.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
