LB-Yu commented on code in PR #1477:
URL: https://github.com/apache/fluss/pull/1477#discussion_r2288049580
##########
fluss-server/src/main/java/com/alibaba/fluss/server/zk/ZooKeeperClient.java:
##########
@@ -222,8 +222,27 @@ public void deleteTableAssignment(long tableId) throws
Exception {
public void deletePartitionAssignment(long partitionId) throws Exception {
String path = PartitionIdZNode.path(partitionId);
- zkClient.delete().deletingChildrenIfNeeded().forPath(path);
- LOG.info("Deleted table assignment for partition id {}.", partitionId);
+ // delete partition assignment ZNode will recursively delete all the
children which may
Review Comment:
> > Could this introduce inconsistent behavior during coordinator failover?
Should we consider using ZooKeeper TransactionOp to solve this problem? I think
dividing the ZK delete operation into asynchronous background sub-tasks may
compromise the integrity of the DROP semantic. @wuchong What are your thoughts
on this?
>
> Recursively delete children nodes cannot execute in TransactionOp. To
ensure that PartitionAssignment can be completely removed during
CoordinatorServer failover, I only remove the partition to be deleted from the
CoordinatorContext after receiving a successful ZooKeeper deletion callback. In
this way, if a failure occurs during the deletion process, it can be retried
after a restart.
After some testing, I abandoned the "only remove the partition to be deleted
from the CoordinatorContext after receiving a successful ZooKeeper deletion
callback" solution. It causes onDeletePartition() to be called multiple times.
--
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]
