[
https://issues.apache.org/jira/browse/GEODE-9575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17411446#comment-17411446
]
Donal Evans commented on GEODE-9575:
------------------------------------
In addition to the work described above, the
{{PubSubImpl.registerPublishFunction()}} method should be refactored by pulling
out the anonymous {{InternalFunction}} that gets created there to its own
{{RedisPubSubFunction}} class. This will improve readability and make the
function more testable.
> redis publish sends an extra message to each server
> ---------------------------------------------------
>
> Key: GEODE-9575
> URL: https://issues.apache.org/jira/browse/GEODE-9575
> Project: Geode
> Issue Type: Improvement
> Components: redis
> Reporter: Darrel Schneider
> Priority: Major
>
> The redis publish command uses a geode function to distribute the publish to
> each server that may have subscriptions. When it does this it calls
> PartitionRegionHelper.getPartitionRegionInfo. It turns out the implementation
> of this method sends a message to each data store:
> FetchPartitionDetailsMessage.
> Since all redis publish wanted to do was execute the function on each server
> that has the redis data region, it could have instead done it like so in
> RegionProvider.getRegionMembers:
> {code:java}
> Set<InternalDistributedMember> otherMembers =
> partitionedRegion.getRegionAdvisor().adviseDataStore();
> Set<DistributedMember> result = new HashSet<>(otherMembers.size()+1);
> result.addAll(otherMembers);
>
> result.add(partitionedRegion.getDistributionManager().getDistributionManagerId());
> return result;
> {code}
> When I did this I started seeing one of the tests fail. It looked like it
> might had to do with something left around from one test method interfering
> with another. It is possible that the older slow code works in this test
> because the extra messaging slows publish down. It was a dunit test that did
> some ha (starting and stopping servers). I verified that this code does
> produce the same set of members as the old code but I did not figure out what
> was wrong with the test that started failing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
