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 enforcement by using multiple client-ids (either insidiously to go beyond its allocated quota or with good intention to avoid the metric collision issue)
Name mangling works but I think less useful than an explicit metric-id (perhaps that could be an optional configuration) in that we would need to somehow correlate the mangled name with the actual code (say, when looking at a threaddump or looking at request logs). btw, the proposal in KIP-55 would work for authenticated clients - i.e., the application can instantiate multiple clients with different client-ids but same quota id (authenticated user) and avoids a wire-protocol change, but we ideally should have something that also works for non-authenticated clients. Between an explicit quota-id field and an instance disambiguation scheme (i.e., metric id) I would vote for the latter. On Fri, Apr 29, 2016 at 1:06 AM, Onur Karaman <onurkaraman.apa...@gmail.com> > wrote: > alternative is to make quotas depend on a quota id instead of client-id > (as > > brought up in KIP-55), but this means we no longer can quota older > clients > > out of the box. > If we do have a new quota-id then we can still quota older clients - i.e., if the inbound request has a newer API version that has a quota-id then use that - otherwise use the client-id. Joel
