AndrewJSchofield commented on code in PR #22766:
URL: https://github.com/apache/kafka/pull/22766#discussion_r3585332343
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/ShareConsumeRequestManager.java:
##########
@@ -907,7 +920,14 @@ private void handleShareFetchSuccess(Node fetchTarget,
if (partitionData.currentLeader().leaderId() != -1 &&
partitionData.currentLeader().leaderEpoch() != -1) {
partitionsWithUpdatedLeaderInfo.put(tip.topicPartition(), new
Metadata.LeaderIdAndEpoch(
Optional.of(partitionData.currentLeader().leaderId()),
Optional.of(partitionData.currentLeader().leaderEpoch())));
+
+ maybeUpdateLeaderCache(tip,
partitionData.currentLeader().leaderId(),
partitionData.currentLeader().leaderEpoch());
Review Comment:
The awareness of the assigned partitions comes from `SubscriptionState` in
the `fetchablePartitions()` call at the start of the poll. So, yes, I think it
is possible that a partition might not be assigned any more by the time we hit
this. However, because share groups have intentionally looser semantics than
consumer groups, this is expected. If a share consumer receives some records
from an assigned partition, and then the partition is revoked, it is still able
to continue delivery of those records and complete their acknowledgements,
potentially for a significant length of time (renew acks).
--
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]
