[
https://issues.apache.org/jira/browse/KAFKA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17893352#comment-17893352
]
kangning.li commented on KAFKA-17804:
-------------------------------------
hello [~junrao]
Currently, about the fetch purgatory, the logic of "make follower" is as
follows:
* CASE 1: If the current replica is follower, and the leader replica id does
not change, indicate that current replica state is already correct and the
become-follower steps can be skipped.
* CASE 2: If not, it will trigger the purgatory check.
In CASE 2:
# If fetch from follower, it will check the "delay fetch purgatory" to make
the request fail fast.
# If fetch from consumer
# If client configuration item "client.rack" is set, that means requests can
be pulled from follower, the "delay fetch purgatory" will NOT be triggered
# If not, that means requests must be pulled from leader, it will check the
"delay fetch purgatory" to make the request fail fast
So I think current logic is correct, maybe it doesn't need to be adjusted.
WDYT ? :)
> optimize ReplicaManager.completeDelayedOperationsWhenNotPartitionLeader
> -----------------------------------------------------------------------
>
> Key: KAFKA-17804
> URL: https://issues.apache.org/jira/browse/KAFKA-17804
> Project: Kafka
> Issue Type: Improvement
> Components: core
> Reporter: Jun Rao
> Assignee: kangning.li
> Priority: Minor
>
> Currently, ReplicaManager.completeDelayedOperationsWhenNotPartitionLeader is
> called when (1) a replica is removed from the broker and (2) a replica
> becomes a follower replica and it checks the completion of multiple
> purgatories. However, not all purgatories need to be checked in both
> situations. For example, the fetch purgatory doesn't need to be checked in
> case (2) since we support fetch from follower now.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
