Hey Stan, > We will introduce two new configs in order to eventually replace *.replication.throttled.rate. Just to clarify, you mean to replace said config in the context of reassignment throttling, right? We are not planning to remove that config
Yes, I don't want to remove that config either. Removed that sentence. And also to clarify, *.throttled.replicas will not apply to the new *reassignment* configs, correct? We will throttle all reassigning replicas. (I am +1 on this, I believe it is easier to reason about. We could always add a new config later) Are you asking whether there is a need for a leader.reassignment.throttled.replicas and follower.reassignment.throttled.replicas config or are you interested in the behavior between the old and the new configs? As for the first question I think is no need for *.throttled.replicas in case of reassignment because the LeaderAndIsrRequest exactly specifies the replicas needed to be throttled. As for the second, see below. I have one comment about backwards-compatibility - should we ensure that the old `*.replication.throttled.rate` and `*.throttled.replicas` still apply to reassigning traffic if set? We could have the new config take precedence, but still preserve backwards compatibility. Sure, we should apply replication throttling to reassignment too if set. But instead of the new taking precedence I'd apply whichever has lower value. For instance a bootstrapping server where all replicas are throttled and there are reassigning replicas and the reassignment throttle set higher I think we should still apply the replication throttle to ensure the broker won't have problems. What do you think? Thanks, Viktor On Fri, Nov 1, 2019 at 9:57 AM Stanislav Kozlovski <stanis...@confluent.io> wrote: > Hey Viktor. Thanks for the KIP! > > > We will introduce two new configs in order to eventually replace > *.replication.throttled.rate. > Just to clarify, you mean to replace said config in the context of > reassignment throttling, right? We are not planning to remove that config > > And also to clarify, *.throttled.replicas will not apply to the new > *reassignment* configs, correct? We will throttle all reassigning replicas. > (I am +1 on this, I believe it is easier to reason about. We could always > add a new config later) > > I have one comment about backwards-compatibility - should we ensure that > the old `*.replication.throttled.rate` and `*.throttled.replicas` still > apply to reassigning traffic if set? We could have the new config take > precedence, but still preserve backwards compatibility. > > Thanks, > Stanislav > > On Thu, Oct 24, 2019 at 1:38 PM Viktor Somogyi-Vass < > viktorsomo...@gmail.com> > wrote: > > > Hi People, > > > > I've created a KIP to improve replication quotas by handling reassignment > > related throttling as a separate case with its own configurable limits > and > > change the kafka-reassign-partitions tool to use these new configs going > > forward. > > Please have a look, I'd be happy to receive any feedback and answer > > all your questions. > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-542%3A+Partition+Reassignment+Throttling > > > > Thanks, > > Viktor > > > > > -- > Best, > Stanislav >
