[
https://issues.apache.org/jira/browse/GEODE-6730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864283#comment-16864283
]
ASF subversion and git services commented on GEODE-6730:
--------------------------------------------------------
Commit 799c0767ecb88366ee7842343e4cce2e6d616ab0 in geode's branch
refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=799c076 ]
GEODE-6730: optimize check for sender id differences (#3707)
GEODE-6866: log warning instead of throwing exception
This revision fixes both GEODE-6730 and GEODE-6866
Throwing an exception led to inconsistency because the operation made it into
the region but not into the gateway sender or async event queue.
Once the warning is logged for a region it will not be logged again until a
check is done that finds that the ids are consistent.
I had both the initial message (that the ids differ) and the subsequent message
(that they are now consistent) both be logged as warnings so that if you see
the first message you will also see the second.
If we logged the "everything is ok" at info level, then it is possible that
they would only see the warning.
I thought it was best to at least have this log message instead of completely
removing the check. It may help diagnose a case in the future when someone
dynamically adds a gateway sender inconsistently.
> 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
> 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
(v7.6.3#76005)
