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 2021/09/16 23:33:00 UTC

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

     [ https://issues.apache.org/jira/browse/GEODE-9575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darrel Schneider resolved GEODE-9575.
-------------------------------------
    Fix Version/s: 1.15.0
       Resolution: Fixed

> 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
>            Assignee: Darrel Schneider
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.15.0
>
>
> 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)