-
Notifications
You must be signed in to change notification settings - Fork 92
Fix #18 duplicate reassignment #106
Fix #18 duplicate reassignment #106
Conversation
could we start with adding a unit test that can reproduce the issue? |
@@ -599,9 +599,10 @@ public UnderReplicatedReason getUnderReplicatedReason(String brokerHost, | |||
List<OutOfSyncReplica> outOfSyncReplicas) { | |||
Map<TopicPartition, Integer[]> replicasMap = new HashMap<>(); | |||
boolean success = true; | |||
|
|||
PriorityQueue<KafkaBroker> brokerQueue = kafkaCluster.getBrokerQueue(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
brokerQueue
is used in KafkaCluster.getAlternativeBrokers
, and the priority queue ordering invariant is maintained in that method.
for (OutOfSyncReplica oosReplica : outOfSyncReplicas) { | ||
// rebuild broker queue each time to get up-to-date results | ||
brokerQueue = kafkaCluster.getBrokerQueue(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kafkaCluster.getBrokerQueue()
is an expensive operation. As long as we maintain the priority queue ordering invariant, we do not need to recompute the priority queue for each out of sync replica.
…orkafka into fix-duplicate-reassignment
Test added to reproduce issue, updated fix to avoid costly operations. |
@kabochya Thanks for making the fix! |
Addressing #18
Duplicate reassignment will happen when multiple outOfSyncReplicas exist and target broker is still least used broker.
Creating the broker queue each time so we don't need to deal with recovering the brokerQueue for next outOfSyncReplica