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 >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > >
