C0urante commented on code in PR #12561:
URL: https://github.com/apache/kafka/pull/12561#discussion_r964939766
##########
connect/runtime/src/main/java/org/apache/kafka/connect/runtime/distributed/IncrementalCooperativeAssignor.java:
##########
@@ -285,18 +292,13 @@ ClusterAssignment performTaskAssignment(
handleLostAssignments(lostAssignments, newSubmissions,
completeWorkerAssignment);
+ if (delay > 0) {
+ log.debug("Delaying {}ms for revoking tasks.", delay);
+ }
// Do not revoke resources for re-assignment while a delayed rebalance
is active
- // Also we do not revoke in two consecutive rebalances by the same
leader
- canRevoke = delay == 0 && canRevoke;
-
- // Compute the connectors-and-tasks to be revoked for load balancing
without taking into
- // account the deleted ones.
- log.debug("Can leader revoke tasks in this assignment? {} (delay:
{})", canRevoke, delay);
- if (canRevoke) {
+ if (delay == 0) {
Map<String, ConnectorsAndTasks> toExplicitlyRevoke =
- performTaskRevocation(activeAssignments,
currentWorkerAssignment);
-
- log.debug("Connector and task to revoke assignments: {}",
toRevoke);
+ performTaskRevocation(configured,
completeWorkerAssignment);
Review Comment:
Switching from `configured` to `activeAssignments` helps in some scenarios,
but not others. I found a few cases to demonstrate this while reviewing
https://github.com/apache/kafka/pull/10367, documented
[here](https://github.com/apache/kafka/pull/10367#discussion_r810393411).
I wonder if we can leave this change out for now and then address the
remaining issues with incremental rebalancing in a follow-up PR? There are a
lot of edge cases to consider and I don't want to block the primary change here
of allowing consecutive revocations (which is super useful on its own!) by
tying it to thinking through all the implications for a change that can be made
independently.
@showuon what are your thoughts?
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
