[jira] [Commented] (GEODE-9575) redis publish sends an extra message to each server

["Donal Evans (Jira)" <ji...@apache.org>]

    [ 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)