[
https://issues.apache.org/jira/browse/KAFKA-7509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507833#comment-17507833
]
Matthias J. Sax commented on KAFKA-7509:
----------------------------------------
Personally, I think the best way would be to tackle this with a KIP across the
board: not just for connect. The idea would be to allow user to add a prefix to
the config they want to "forward" to "inner" classes. For example, if an
interceptor needs a config, we could use `interceptor.foo.bar` instead of
`foo.bar` – this way, we know that the consumer/producer can ignore this
config, and when we forward the config into the interceptor, we actually remove
`interceptor` prefix.
The `interceptor` prefix would of course be quite specific (and it only works
because interceptors are a Kafka concept). We could also generalize it using a
prefix `forward.`.
In Kafka Streams, we are already using `main.consumer.`, `restore.consumer.`,
and `producer.` as prefix to allow users to configure individual client and to
avoid that `StreamsConfig` logs warnings about "unknown" client config.
The advantage of the prefix approach is, that is it much more fine-grained
compared to a config, and it can also be applies recursively. For example, in
Kafka Streams we use an `AdminClient` inside the `ConsumerClient`. If we want
to configure the admin client, we can provide
`main.consumer.forward.actualAdminConfigName` and avoid that the consumer logs
a warning about an unknown client.
> Kafka Connect logs unnecessary warnings about unused configurations
> -------------------------------------------------------------------
>
> Key: KAFKA-7509
> URL: https://issues.apache.org/jira/browse/KAFKA-7509
> Project: Kafka
> Issue Type: Improvement
> Components: clients, KafkaConnect
> Affects Versions: 0.10.2.0
> Reporter: Randall Hauch
> Priority: Major
>
> When running Connect, the logs contain quite a few warnings about "The
> configuration '{}' was supplied but isn't a known config." This occurs when
> Connect creates producers, consumers, and admin clients, because the
> AbstractConfig is logging unused configuration properties upon construction.
> It's complicated by the fact that the Producer, Consumer, and AdminClient all
> create their own AbstractConfig instances within the constructor, so we can't
> even call its {{ignore(String key)}} method.
> See also KAFKA-6793 for a similar issue with Streams.
> There are no arguments in the Producer, Consumer, or AdminClient constructors
> to control whether the configs log these warnings, so a simpler workaround
> is to only pass those configuration properties to the Producer, Consumer, and
> AdminClient that the ProducerConfig, ConsumerConfig, and AdminClientConfig
> configdefs know about.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
