If I understand you correctly, you are saying: 1. KIP-190 will not affect anyone who doesn't use special characters in their client IDs 2. Those who have special characters in client IDs already have tons of metrics issues and won't be inconvenienced by a KIP that fixes them.
Did I get it right? On Sat, Sep 9, 2017 at 9:54 AM Mickael Maison <mickael.mai...@gmail.com> wrote: > Hi Gwen, thanks for taking a look at the KIP. > > I understand your concern trying to make the transition as smooth as > possible. However there are several issues with the way client-ids > with special characters are handled: > Client-ids that contain invalid ObjectName characters (colon, equals, > etc) currently fail to be registered by the build-in JMX reporter so > they already don't appear in all monitoring systems ! These also cause > issues with Quotas. > > The Java clients as well as the kafka-configs.sh tool already reject > them (even though the error you get from the Produce/Consumer is > pretty cryptic). > > People currently using client-ids with special characters have to be > running 3rd party clients and probably encounter strange quotas issues > as well as missing metrics (if they use JMX). > > So if we really want to do the smallest possible change, we could only > encode ObjectName special characters instead of all special > characters. That way at least the JMX reporter would work correctly. > Display a warning when using any other special characters. Then in a > later release, encode everything like we currently do for the > User/Principal. > > What do you think ? > > On Fri, Sep 1, 2017 at 7:33 AM, Gwen Shapira <g...@confluent.io> wrote: > > Thanks for bumping this. I do have a concern: > > > > This proposal changes the names of existing metrics - as such, it will > > require all owners of monitoring systems to update their dashboards. It > > will also complicate monitoring of multiple clusters with different > > versions and require some modifications to existing monitoring automation > > systems. > > > > What do you think of an alternative solution: > > 1. For the next release, add the validations on the broker side and > print a > > "warning" that this client id is invalid, that it will break metrics and > > that it will be rejected in newer versions. > > 2. Few releases later, actually turn the validation on and return > > InvalidClientID error to clients. > > > > We did something similar when we deprecated acks=2. > > > > Gwen > > > > > > On Thu, Aug 31, 2017 at 12:13 PM Mickael Maison < > mickael.mai...@gmail.com> > > wrote: > > > >> Even though it's pretty non controversial, I was expecting a few > comments. > >> I'll wait until next week for comments then I'll start the vote. > >> > >> Thanks > >> > >> On Mon, Aug 21, 2017 at 6:51 AM, Mickael Maison > >> <mickael.mai...@gmail.com> wrote: > >> > Hi all, > >> > > >> > I have created a KIP to cleanup the way client-ids are handled by > >> > brokers and clients. > >> > > >> > Currently the Java clients have some restrictions on the client-ids > >> > that are not enforced by the brokers. Using 3rd party clients, > >> > client-ids containing any characters can be used causing some strange > >> > behaviours in the way brokers handle metrics and quotas. > >> > > >> > Feedback is appreciated. > >> > > >> > Thanks > >> >
