[
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)
