[
https://issues.apache.org/jira/browse/KAFKA-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16491364#comment-16491364
]
Kevin Lafferty commented on KAFKA-6937:
---------------------------------------
I was able to test this patch today, and it looks good:
# I kicked off a full reassignment on a topic with a single partition while
running constant produce traffic against the cluster. I started the
reassignment with a throttle smaller than the baseline outgoing replication for
the leader, and the outgoing replication was unchanged, starving out the
out-of-sync replicas.
# I then increased the throttle beyond baseline replication, but not high
enough for the out-of-sync replicas to catch up, and the out-of-sync replicas
were able to start replicating data, while the in-sync replicas' rate was
unaffected. The total output was limited to the throttle rate.
# Increasing the throttle further allowed the out-of-sync replicas to catch up.
One thing that was slightly unexpected (but which seems to be the intended
behavior) is that the in-sync replicas counted against the replication quota,
even though they cannot get throttled.
> In-sync replica delayed during fetch if replica throttle is exceeded
> --------------------------------------------------------------------
>
> Key: KAFKA-6937
> URL: https://issues.apache.org/jira/browse/KAFKA-6937
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 0.11.0.1, 1.1.0, 1.0.1
> Reporter: Jun Rao
> Assignee: Jun Rao
> Priority: Major
>
> When replication throttling is enabled, in-sync replica's traffic should
> never be throttled. However, in DelayedFetch.tryComplete(), we incorrectly
> delay the completion of an in-sync replica fetch request if replication
> throttling is engaged.
> The impact is that the producer may see increased latency if acks = all. The
> delivery of the message to the consumer may also be delayed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
