Nicklee007 opened a new pull request, #16563:
URL: https://github.com/apache/pulsar/pull/16563

   ### Motivation
   As  the [PIP 7: Pulsar Failure domain and Anti affinity 
namespaces](https://github.com/apache/pulsar/wiki/PIP-7:-Pulsar-Failure-domain-and-Anti-affinity-namespaces#how-to-create-domain-and-register-brokers)
 design, the anti affinity namespaces should be distributed to  evenly across 
all domain and all the brokers.
   But in method `getAntiAffinityNamespaceOwnedBrokers` , 
`brokerToAntiAffinityNamespaceCount` add a count even the namespace  equal the 
given bundle's namespace which will be load. The behavior will cause the 
namespace easy to distributed to 
    a broker which has another namespace in anti affinity group,   the behavior 
broke the  anti affinity balance. It's better behavior is the same namespace 
should be distributed to those broker which has loaded the same namespace when 
all broker have load at least one namespace in ti affinity group.
   
    there is some case 
   `broker-0` own `ns-0 bundle-0`;  
   `broker-1` own `ns-1 bundle-0`; 
   `broker-2 `own `ns-2 bundle-0`;
     then another ` ns-2 bundle-1` need choice a broker to load. As the old 
policy, `broker-0 broker-1 and broker-2` are all satisfy the least 
NamespaceCount; but if  `ns-2 bundle-1` load to `broker-0 or broker-1 `will 
broke the anti affinity balance.  `ns-2 bundle-1` need be load by broker-2 is 
better.
   
   Also, the the behavior will cause give up `doLoadShedding` when the all 
broker own one namespace in anti affinity group, but the different broker owned 
namespace bundle count and payload is different.
   So `brokerToAntiAffinityNamespaceCount` should exclude  the same namespace 
as the given.
   
   ### Modifications
   1. In LoadManagerShared.class  `getAntiAffinityNamespaceOwnedBrokers` 
method,  exclude  the given namespace count add.
   2.  changed `shouldAntiAffinityNamespaceUnload` check;
   3. add some unit test.
   
   ### Documentation
   - [X] `doc-not-needed` 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to