Hi Ismael,
Sorry, I had missed your note earlier. Jun had suggested changing the quota
callback methods so that there is only one method to obtain quota limits.
We used to have two methods, one which returned (*quotaLimit+metricTags)* and
another which returned *quotaLimit* given the *metricTags.*
Hi Rajini,
Can you share the motivation for the change? Not sure if the new approach
is better.
Ismael
On Thu, Apr 5, 2018 at 4:06 PM, Rajini Sivaram
wrote:
> The quota callback interface was updated based on Jun's suggestion during
> the PR review. I have updated the KIP to reflect this.
>
>
The quota callback interface was updated based on Jun's suggestion during
the PR review. I have updated the KIP to reflect this.
Let me know if there are any concerns.
Thanks,
Rajini
On Thu, Apr 5, 2018 at 1:04 PM, Rajini Sivaram
wrote:
> Thanks, Ismael.
>
> I have updated the KIP and the PR.
Thanks, Ismael.
I have updated the KIP and the PR.
On Wed, Apr 4, 2018 at 7:37 PM, Ismael Juma wrote:
> Sounds good to me Rajini. Good catch spotting this before it's included in
> a release. :)
>
> Ismael
>
> On Wed, Apr 4, 2018 at 11:13 AM, Rajini Sivaram
> wrote:
>
> > For compatibility rea
Sounds good to me Rajini. Good catch spotting this before it's included in
a release. :)
Ismael
On Wed, Apr 4, 2018 at 11:13 AM, Rajini Sivaram
wrote:
> For compatibility reasons, we are now using Java rather than Scala for all
> pluggable interfaces including those on the broker. There is alre
For compatibility reasons, we are now using Java rather than Scala for all
pluggable interfaces including those on the broker. There is already a KIP
to move Authorizer to Java as well. As we will be removing support for Java
7 in the next release, we can also use default methods in Java when we ne
Since there all the comments so far have been addressed, I will start vote
for this KIP.
Regards,
Rajini
On Thu, Mar 15, 2018 at 6:37 PM, Rajini Sivaram
wrote:
> Thanks, Jun.
>
> 11. updatePartitionMetadata() provides all partitions with their leaders
> so that callbacks that scale down quotas
Thanks, Jun.
11. updatePartitionMetadata() provides all partitions with their leaders so
that callbacks that scale down quotas based on fraction of partitions
hosted on each broker may compute the scaling factor. Callbacks that scale
up quotas based on the partition count hosted on each broker can
Hi, Rajini,
Thanks for the explanation. It makes sense.
11. We probably want to clarify in the interface that every time when
updatePartitionMetadata() is called, the full list of partitions whose
leader is on this broker will be passed in?
Jun
On Thu, Mar 15, 2018 at 4:42 AM, Rajini Sivaram
w
Hi Jun,
12. Sorry, I had to revert the change that removed `
ClientQuotaCallback.quotaLimit()`. We are allowing quota callbacks to use
custom metric tags. For each request, quota manager uses `
ClientQuotaCallback.quota()` to map (user-principal, client-id) to the
metric tags that determine which
Hi Jun,
Thank you for reviewing the KIP.
10. This is the current behaviour (this KIP retains the same behaviour for
the default quota callback). We include 'user' and 'client-id' tags in all
the quota metrics, rather than omit tags at the moment.
11. Ah, I hadn't realised that. I wasn't expectin
Hi, Rajini,
Thanks for the KIP. Looks good overall. A few comments below.
10. "If quota config is used, *user* tag is set to user principal of
the session and *client-id* tag is set to empty string. " Could we just
omit such a tag if the value is empty?
11. I think Viktor has a valid point on h
Hi Rajini,
Well, I didn't really have specific use cases for having other metadata
(like isr and replicas), just thought it would be a more robust interface.
But yea, since currently there are no specific use cases, it makes sense
not to include them.
Viktor
On Tue, Mar 13, 2018 at 10:47 AM, Raj
I have submitted a PR with the changes proposed in this KIP (
https://github.com/apache/kafka/pull/4699). I added an additional method to
the quota callback in the KIP to simplify metrics updates when quotas are
updated.
Feedback and suggestions are welcome. If there are no other concerns, I
will
Hi Viktor,
Thanks for reviewing the KIP.
1. Yes, that is correct. Typically quotas would depend only on the current
partition state. But if you did want to track deleted partitions, you can
calculate the diff.
2. I can't think of an use case where ISRs or other replica information
would be useful
Hi Rajini,
I've read through your KIP and it looks good, I only have two things to
clarify.
1. How do we detect removed partitions in updatePartitionMetadata? I'm
presuming that the list here is the currently existing map of partitions,
so if something is removed it can be calculated as the diff o
Hi all,
I have submitted KIP-257 to enable customisation of client quota
computation:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-257+-+Configurable+Quota+Management
The KIP proposes to make quota management pluggable to enable group-based
and partition-based quotas for clients.
Feed
17 matches
Mail list logo
