Looking at where the log message comes from: org.apache.kafka.common.config.AbstractConfig#logUnused it seems like maybe the warning just happens when you pass extra configs to a client that it has no knowledge of (and therefore doesn't "use").
I'm now suspicious if Streams is actually sending extra configs to the clients, although it seems like we _don't_ see these warnings in other cases. Maybe some of the folks who actually see these messages can try to pinpoint where exactly the rogue configs are coming from? I might have overlooked a message at some point, but it wasn't clear to me that we were talking about warnings that were actually caused by Streams. I thought the unknown configs were something user-specified. Thanks, -John On Fri, Feb 7, 2020, at 13:10, Gwen Shapira wrote: > Ah, got it! I am indeed curious why they do this :) > > Maybe John can shed more light. But if we can't find a better fix, > perhaps the nice thing to do is really a separate logger, so users who > are not worried about shooting themselves in the foot can make those > warnings go away. > > Gwen Shapira > Engineering Manager | Confluent > 650.450.2760 | @gwenshap > Follow us: Twitter | blog > > On Fri, Feb 07, 2020 at 4:13 AM, Patrik Kleindl < pklei...@gmail.com > wrote: > > > > > > > > > Hi Gwen > > > > > > > > Kafka Streams is not a third party library and produces a lot of these > > warnings, e.g. > > > > > > > > *The configuration 'main.consumer.max.poll.records' was supplied but isn't > > a known config.* > > *The configuration 'admin.retries' was supplied but isn't a known config.* > > and various others if you try to fine-tune the restoration consumer or > > inject parameters for state stores. > > This results in a lot of false positives and only makes new people worried > > and then ignore the warnings altogether. > > > > > > > > Unless this is taken care of at least the Kafka Streams users will > > probably be better off having this on debug level. > > > > > > > > Best regards > > > > > > > > Patrik > > > > > > > > On Thu, 6 Feb 2020 at 16:55, Gwen Shapira < gwen@ confluent. io ( > > g...@confluent.io ) > wrote: > > > > > >> > >> > >> INFO is the default log level, and while it looks less "alarming" than > >> WARN, users will still see it and in my experience, they will worry that > >> something is wrong anyway. Or if INFO isn't the default, users won't see > >> it, so it is no different from debug and we are left with no way of > >> warning users that they misconfigured something. > >> > >> > >> > >> The point is that "known configs" exist in Kafka as a validation step. It > >> is there to protect users. So anything that makes the concerns about > >> unknown configs invisible to users, makes the validation step useless and > >> we may as well remove it. I'm against that - I think users should be made > >> aware of misconfigs as much as possible - especially since if you misspell > >> > >> "retention", you will lose data. > >> > >> > >> > >> If we look away from the symptom and go back to the actual cause.... > >> > >> > >> > >> I think Kafka had a way (and maybe it still does) for 3rd party developers > >> who create client plugins (mostly interceptors) to make their configs > >> "known". 3rd party developers should be responsible for the good > >> experience of their users. Now it is possible that you'll pick a 3rd party > >> library that didn't do it and have a worse user experience, but I am not > >> sure it is the job of Apache Kafka to protect users from their choice of > >> libraries > >> (and as long as those libraries are OSS, users can fix them). Especially > >> not at the expense of someone who doesn't use 3rd party libs. > >> > >> > >> > >> Gwen > >> > >> > >> > >> Gwen Shapira > >> Engineering Manager | Confluent > >> 650.450.2760 | @gwenshap > >> Follow us: Twitter | blog > >> > >> > >> > >> On Thu, Feb 06, 2020 at 2:06 AM, Artur Burtsev < artjock@ gmail. com ( > >> artj...@gmail.com ) > wrote: > >> > >> > >>> > >>> > >>> Hi John, > >>> > >>> > >>> > >>> In out case it wont help, since we are running instance per partition and > >>> even with summary only we get 32 warnings per rollout. > >>> > >>> > >>> > >>> Hi Gwen, > >>> > >>> > >>> > >>> Thanks for you reply, I understand and share your concern, I also > >>> mentioned it earlier in the thread. Do you think it will work if we > >>> > >>> > >> > >> > >> > >> change > >> > >> > >>> > >>> > >>> DEBUG to INFO? > >>> > >>> > >>> > >>> Thanks, > >>> Artur > >>> > >>> > >>> > >>> On Thu, Feb 6, 2020 at 4:21 AM Gwen Shapira < gwen@ confluent. io ( gwen@ > >>> confluent. > >>> io ( g...@confluent.io ) ) > wrote: > >>> > >>> > >>>> > >>>> > >>>> Sorry for late response. The reason that unused configs is in WARN is > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> that > >> > >> > >>> > >>>> > >>>> > >>>> if you misspell a config, it means that it will not apply. In some cases > >>>> (default retention) you want know until too late. We wanted to warn > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> admins > >> > >> > >>> > >>>> > >>>> > >>>> about possible misconfigurations. > >>>> > >>>> > >>>> > >>>> In the context of a company supporting Kafka - customers run logs at > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> INFO > >> > >> > >>> > >>>> > >>>> > >>>> level normally, so if we suspect a misconfiguration, we don't want to > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> ask > >> > >> > >>> > >>>> > >>>> > >>>> the customer to change level to DEBUG and bounce the broker. It is time > >>>> consuming and can be risky. > >>>> > >>>> > >>>> > >>>> *Gwen Shapira* > >>>> Product Manager | Confluent > >>>> 650.450.2760 | @gwenshap > >>>> Follow us: Twitter ( https:/ / twitter. com/ ConfluentInc ( https:/ / > >>>> twitter. > >>>> com/ ConfluentInc ( https://twitter.com/ConfluentInc ) ) ) | blog ( > >>>> http:/ > >>>> / www. confluent. > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> io/ > >> > >> > >>> > >>>> > >>>> > >>>> blog ( http:/ / www. confluent. io/ blog ( http://www.confluent.io/blog > >>>> ) ) > >>>> ) > >>>> > >>>> > >>>> > >>>> Sent via Superhuman ( https:/ / sprh. mn/ ?vip=gwen@ confluent. io ( > >>>> https:/ > >>>> / sprh. mn/ ?vip=gwen@ confluent. io ( > >>>> https://sprh.mn/?vip=g...@confluent.io ) ) ) > >>>> > >>>> > >>>> > >>>> On Mon, Jan 06, 2020 at 4:21 AM, Stanislav Kozlovski < stanislav@ > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> confluent. > >> > >> > >>> > >>>> > >>>> > >>>> io ( stanislav@ confluent. io ( stanis...@confluent.io ) ) > wrote: > >>>> > >>>> > >>>>> > >>>>> > >>>>> Hey Artur, > >>>>> > >>>>> > >>>>> > >>>>> Perhaps changing the log level to DEBUG is the simplest approach. > >>>>> > >>>>> > >>>>> > >>>>> I wonder if other people know what the motivation behind the WARN log > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> was? > >> > >> > >>> > >>>> > >>>>> > >>>>> > >>>>> I'm struggling to think up of a scenario where I'd like to see unused > >>>>> values printed in anything above DEBUG. > >>>>> > >>>>> > >>>>> > >>>>> Best, > >>>>> Stanislav > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Dec 30, 2019 at 12:52 PM Artur Burtsev < artjock@ gmail. com > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> ( artjock@ > >> > >> > >>> > >>>> > >>>>> > >>>>> > >>>>> gmail. com ( artjock@ gmail. com ( artj...@gmail.com ) ) ) > wrote: > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> > >>>>>> > >>>>>> Indeed changing the log level for the whole AbstractConfig is not an > >>>>>> option, because logAll is extremely useful. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Grouping warnings into 1 (with the count of unused only) will not be a > >>>>>> good option for us either. It will still be pretty noisy. Imagine we > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> have > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> 32 partitions and scaled up the application to 32 instances then we > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> still > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> have 32 warnings per application (instead of 96 now) while we would > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> like > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> to have 0 warnings because we are perfectly aware of using > >>>>>> schema.registry.url and its totally fine, and we don't have to be > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> warned > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> every time we start the application. Now imagine we use more than one > >>>>>> consumer per application, then it will add another multiplication > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> factor > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> to these grouped warnings and we still have a lot of those. So I > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> would say > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> grouping doesn't help much. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I think adding extra logger like > >>>>>> "org.apache.kafka.clients.producer.ProducerConfig.unused" could be > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> another > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> good option. That would leave the existing interface untouched and > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> give > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> everyone an option to mute irrelevant warnings. > >>>>>> > >>>>>> > >>>>>> > >>>>>> To summarize, I still can see 3 options with its pros and cons > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> discussed > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> in the thread: > >>>>>> 1) extra config with interface to handle unused > >>>>>> 2) change unused warn to debug > >>>>>> 3) add extra logger for unused > >>>>>> > >>>>>> > >>>>>> > >>>>>> Please let me know what do you think. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Artur > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mon, Dec 30, 2019 at 11:07 AM Stanislav Kozlovski > >>>>>> < stanislav@ confluent. io ( stanislav@ confluent. io ( stanislav@ > >>>>>> confluent. > >>>>>> io ( stanis...@confluent.io ) ) ) > wrote: > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Would printing all the unused configurations in one line, versus N > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> lines, > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> be more helpful? I know that it would greatly reduce the verbosity > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> in log > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> visualization tools like Kibana while still allowing us to see all > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> the > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> relevant information without the need for an explicit action (e.g > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> changing > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> the log level) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Best, > >>>>>>> Stanislav > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Sat, Dec 28, 2019 at 3:13 PM John Roesler < vvcephei@ apache. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> org ( vvcephei@ > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> apache. org ( vvcephei@ apache. org ( vvcep...@apache.org ) ) ) > > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Hi Artur, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> That’s a good point. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> One thing you can do is log a summary at WARN level, like “27 > >>>>>>>> configurations were ignored. Ignored configurations are logged at > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> DEBUG > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> level.” > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I looked into the code a little, and these log messages are > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> generated > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> in > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> AbstractConfig (logAll and logUnused). They both use the logger > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> associated > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> with the relevant config class (StreamsConfig, ProducerConfig, > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> etc.). > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> The > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> list of all configs is logged at INFO level, and the list of unused > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> configs > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> is logged at WARN level. This means that it's not possible to > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> silence > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> the > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> unused config messages while still logging the list of all configs. > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> You > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> could only silence both by setting (for example) ProducerConfig > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> logger > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> to > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> ERROR or OFF. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> If it's desirable to be able to toggle them independently, then you > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> can > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> create a separate logger for unused configs, named something like > >>>>>>>> "org.apache.kafka.clients.producer.ProducerConfig.unused". Then, you > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> can > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> leave the log at WARN, so it would continue to be printed by > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> default, > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> and > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> anyone could disable it by setting > >>>>>>>> "org.apache.kafka.clients.producer.ProducerConfig.unused" to ERROR > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> or > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> OFF, > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> without disturbing the rest of the config log messages. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> It's simpler without the extra logger, but you also get less > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> control. > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> Do > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> you think the extra control is necessary, versus printing a summary > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> at > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> WARN > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> level? > >>>>>>>> -John > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Fri, Dec 27, 2019, at 04:26, Artur Burtsev wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Indeed changing log level to debug would be the easiest and I > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> think that > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> would be a good solution. When no one object I'm ready to move > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> forward > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> with this approach and submit a MR. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The only minor thing I have – having it at debug log level might > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> make it a > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> bit less friendly for developers, especially for those who just do > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> the > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> first steps in Kafka. For example, if you misspelled the property > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> name and > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> trying to understand why things don't do what you expect. Having a > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> warning > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> might save some time in this case. Other > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> than > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> that I cannot see any reasons to have warnings there. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Artur > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Thu, Dec 26, 2019 at 10:01 PM John Roesler < vvcephei@ apache. > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> org ( vvcephei@ > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> apache. org ( vvcephei@ apache. org ( vvcep...@apache.org ) ) ) > > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks for the KIP, Artur! > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> For reference, here is the kip: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> https:/ / cwiki. apache. org/ confluence/ display/ KAFKA/ > >>>>>> KIP-552%3A+Add+interface+to+handle+unused+config > >>>>>> ( > >>>>>> https:/ / cwiki. apache. org/ confluence/ display/ KAFKA/ > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> KIP-552%3A+Add+interface+to+handle+unused+config > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> ( > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> https:/ / cwiki. apache. org/ confluence/ display/ KAFKA/ > >> KIP-552%3A+Add+interface+to+handle+unused+config > >> ( > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-552%3A+Add+interface+to+handle+unused+config > >> ) > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> ) > >>>>>> ) > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I agree, these warnings are kind of a nuisance. Would it be > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> feasible > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> just to leverage log4j in some way to make it easy to filter these > >>>>>>>> messages? For example, we could move those warnings to debug level, > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> or > >> > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> even > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> use a separate logger for them. > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks for starting the discussion. > >>>>>>>>>> -John > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Tue, Dec 24, 2019, at 07:23, Artur Burtsev wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> This KIP provides a way to deal with a warning "The > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> configuration {} > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> was supplied but isn't a known config." when it is not relevant. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Cheers, > >>>>>>>>>>> Artur > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Best, > >>>>>>> Stanislav > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Best, > >>>>> Stanislav > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > >
