Major Description
When Quotas where proposed, KIP-13[1] stated:
> In addition, there will be a quota reserved for clients not presenting a client id (for e.g. simple consumers not setting the id). This will default to an empty client id ("") and all such clients will share the quota for that empty id (which should be the default quota).
Though, seems that when client-id is null or empty and a default quota for client-id is present, no quota is applied.
Even though Java clients set a default value [2][3], the protocol accepts null client-id[4], and other clients implementations could send a null value to by-pass a quota.
Related code[5][6] shows that preparing metric pair for quotas with client-id (potentially null) and setting quota to null when both client-id and (sanitize) user are null.
Adding some tests to showcase this: https://github.com/apache/kafka/pull/14165
Is it expected for client-id=null to by-pass quotas? If it is, then KIP or documentation to clarify this; otherwise we should amend this behavior bug. e.g we could "sanitize" client-id similar to user name to be empty string when input is null or empty.
As a side-note, similar behavior could happen with user I guess. Even though value is default to ANONYMOUS, if a client implementation sends empty value, it may as well by-pass the default quota – though I need to further test this once this is considered a bug.
[1]: https://cwiki.apache.org/confluence/display/KAFKA/KIP-13+-+Quotas
Attachments
Issue Links
- links to