lianetm commented on code in PR #16031:
URL: https://github.com/apache/kafka/pull/16031#discussion_r1626147694
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/MembershipManagerImpl.java:
##########
@@ -960,7 +960,7 @@ void maybeReconcile() {
// best effort to commit the offsets in the case where the epoch might
have changed while
// the current reconciliation is in process. Note this is using the
rebalance timeout as
// it is the limit enforced by the broker to complete the
reconciliation process.
- commitResult =
commitRequestManager.maybeAutoCommitSyncBeforeRevocation(getExpirationTimeForTimeout(rebalanceTimeoutMs));
+ commitResult =
commitRequestManager.maybeAutoCommitSyncBeforeRevocation(getDeadlineMsForTimeout(rebalanceTimeoutMs));
Review Comment:
Hey @cadonna, your assumption is right: "the whole reconciliation is limited
by the rebalance timeout", but the trick is that it's the broker who enforces
that, not the client.
That's why we don't see the `rebalanceTimeout` being used on the client
side, other than for sending it to the broker in the initial HB, and here to
limit the commit retries. We use it on the commit only because we needed to put
a limit on the retries to make sure that if the commit keeps failing and being
retried, the request is not kept forever on the client after the broker kicks
the member out of the group.
--
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]
