The proposal in KIP-55 is to have hierarchical quotas with two levels of
hierarchy - quotas assigned to users with sub-quotas assigned to clients
(client-ids) of users. Typically, clients within a JVM run as a single
user, but within a JVM, clients could use different client-ids for the
purpose of
Currently, the only available mechanism to disambiguate between
producer/consumer clients in the same JVM is the client-id. However, that
does not play very well with the current definition of client-id and its
use as the entity for quota enforcement. i.e., an application can thwart
quota
The definition for client id has always been "a logical name for an
application which (potentially) spans more than one process".
>From my point of view the rationalization that is most needed is client id
with "user" for the authenticated cases. There not quite the same but
they're similar.
I
fixing the cc for navina.
On Fri, Apr 29, 2016 at 1:06 AM, Onur Karaman
wrote:
> Hey everyone. I think we might need to have an actual discussion on an
> issue I brought up a while ago in
> https://issues.apache.org/jira/browse/KAFKA-3494. It seems like
>
Hey everyone. I think we might need to have an actual discussion on an
issue I brought up a while ago in
https://issues.apache.org/jira/browse/KAFKA-3494. It seems like client-ids
are being used for too many things today:
1. kafka-request.log. This helps if you ever want to associate a client
with