swuferhong commented on code in PR #1081:
URL: https://github.com/apache/fluss/pull/1081#discussion_r2190037566
##########
fluss-server/src/main/java/com/alibaba/fluss/server/coordinator/statemachine/ReplicaStateMachine.java:
##########
@@ -263,7 +265,9 @@ private void doHandleStateChanges(
// then, may remove the offline replica from isr
Map<TableBucketReplica, LeaderAndIsr> adjustedLeaderAndIsr =
- doRemoveReplicaFromIsr(validReplicas);
+ checkIfDropTableOrPartitionRequest(validReplicas)
+ ? doBatchRemoveReplicaFromIsr(validReplicas)
Review Comment:
Ask a question: Why don’t we design this to be more generic? Instead of
identifying specific operations (e.g., create table/partition, drop
table/partition), why we don't merging buckets by table/partition and perform
batch registration sequentially. If the cluster experiences significant ISR
adjustment (e.g., frequent pod shutdown/starting), would batch registration
become infeasible?
##########
fluss-server/src/main/java/com/alibaba/fluss/server/zk/ZooKeeperClient.java:
##########
@@ -307,6 +307,37 @@ public void updateLeaderAndIsr(TableBucket tableBucket,
LeaderAndIsr leaderAndIs
LOG.info("Updated {} for bucket {} in Zookeeper.", leaderAndIsr,
tableBucket);
}
+ public void batchUpdateLeaderAndIsr(Map<TableBucket, LeaderAndIsr>
batchUpdate)
Review Comment:
Can we integrate this method into `ZookeeperClient`? It appears to be a
generic method with substantial ZooKeeper-specific implementation details.
--
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]
