mjsax commented on code in PR #23484:
URL: https://github.com/apache/kafka/pull/23484#discussion_r4043893155
##########
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/streams/AssignmentRefinerImpl.java:
##########
@@ -520,6 +521,204 @@ private static double currentProcessLoad(
.loadWith(newWarmupsByProcess.getOrDefault(candidate.currentProcessId(), 0));
}
+ /**
+ * Decides which of the target assignment's standby placements this step
has to hold back.
+ *
+ * <p>Nothing is invented or dropped permanently: every placement comes
from the target assignment, and one held
+ * back here is emitted by a later step once its reason is gone. A
placement of task {@code t} on member {@code m}
+ * of process {@code p} is withheld when:
+ * <ol>
+ * <li>{@code p} currently runs {@code t} as an active task, because
{@code t}'s migration off {@code p} is
+ * staged: F moved {@code t}'s active off {@code p} and relocated its
standby, but the refiner held the active
+ * in place, so F's standby cannot land on {@code p} yet.</li>
+ * <li>{@code t}'s migration onto {@code p} borrowed an existing
standby on {@code p}. To not run
Review Comment:
Yes, we want to save as warmup slot. -- We could totally convert the standby
into a warmup, and migrate the standby to it's new owner, but saving a slot
allows us to warmup t on p "for free", and the cost is only a delayed migration
of the standby to it's new owner.
Btw: if we don't have any other more important warm-ups to fund, we would
actually do the standby->warmup conversion.
--
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]
