coltmcnealy-lh commented on code in PR #20833:
URL: https://github.com/apache/kafka/pull/20833#discussion_r2525674447
##########
streams/src/main/java/org/apache/kafka/streams/processor/internals/StreamsPartitionAssignor.java:
##########
@@ -1458,6 +1458,14 @@ protected boolean maybeUpdateSubscriptionVersion(final
int receivedAssignmentMet
@Override
public void onAssignment(final Assignment assignment, final
ConsumerGroupMetadata metadata) {
+ final Set<Task> tasksWithOpenTransactions = taskManager.allOwnedTasks()
+ .values()
+ .stream()
+ .filter(t -> t.commitNeeded())
Review Comment:
Yes, it does make sense that the onAssignment() would only be called after
the rest of the rebalance completes, and perhaps the Group Coordinator doesn't
care to consider the rebalance as "ongoing" while the group members are
handling onAssignment().
Anecdotally, the rebalance-latency-avg consumer metric was quite low (few
hundred milliseconds) during the case when we had StreamThreads blocking for
>20 seconds waiting for TaskManager to finish its assignment. (As a Kafka
non-expert) I think that lends credence to the idea that the GC considers the
rebalance to be "done" at this point.
--
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]
