You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Randall Hauch (Jira)" <ji...@apache.org> on 2020/06/24 20:04:02 UTC

[jira] [Updated] (KAFKA-9510) Quotas may resolve to incorrect value if user is empty

     [ https://issues.apache.org/jira/browse/KAFKA-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated KAFKA-9510:
---------------------------------
    Fix Version/s:     (was: 2.6.0)
                   2.7.0

Since this is not a blocker issue, as part of the 2.6.0 release process I'm changing the fix version to `2.7.0`. If this is incorrect, please respond and discuss on the "[DISCUSS] Apache Kafka 2.6.0 release" discussion mailing list thread.

> Quotas may resolve to incorrect value if user is empty
> ------------------------------------------------------
>
>                 Key: KAFKA-9510
>                 URL: https://issues.apache.org/jira/browse/KAFKA-9510
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Brian Byrne
>            Assignee: Rajini Sivaram
>            Priority: Major
>             Fix For: 2.7.0
>
>
> This may be a pretty rare/uncommon case that I encountered during testing regarding an empty user. [~rsivaram] please let me know if this is a valid bug and whether it's something that's needs further examination.
> Let's say two quota configurations are populated:
> /config/users/<default> {producer_byte_rate=500}
> /config/clients/<default> {producer_byte_rate=1000}
> And let's say a produce request with {user="", client-id="test"} enters the system. When calling ClientQuotaManager::quota(), the metrics tags that are fetched via ClientQuotaCallback::quotaMetricTags() will map to the config entry for /config/users/<default>, which is (sanitizedUser, ""), where substituting gets ("", "").
> Then, when looking up the quota in ClientQuotaCallback::quotaLimit(), both tags are the empty string, which resolves to null, which turns into Long.MaxValue for the result. So where the client may have expected 500 (or 1000?), it's instead unbounded.
> Is it valid for a request to ever contain an empty string for the user? If so, then a fix will be needed, otherwise if not, we should safeguard against this from happening.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)