[
https://issues.apache.org/jira/browse/KAFKA-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ewen Cheslack-Postava updated KAFKA-2026:
-----------------------------------------
Description:
This is a really simple issue. When AbstractConfig logs unused messages, it
gets the value from the parsed configs. Since those are generated from the
ConfigDef, they value will not have been parsed or copied over from the
original map. This is especially confusing if you've explicitly set an option
to pass through to the serializers since you're always going to see these
warnings in your log.
The simplest patch would grab the original value from this.originals. But now
I'm not sure logging this makes sense at all anymore since configuring any
serializer that has options that aren't in ProducerConfig will create a
misleading warning message. Further, using AbstractConfig for your serializer
implementation would cause all the producer's config settings to be logged as
unused. Since a single set of properties is being used to configure multiple
components, trying to log unused keys may not make sense anymore.
Example of confusion caused by this:
http://mail-archives.apache.org/mod_mbox/kafka-users/201503.mbox/%3CCAPAVcJ8nwSVjia3%2BH893V%2B87StST6r0xN4O2ac8Es2bEXjv1OA%40mail.gmail.com%3E
was:
This is a really simple issue. When AbstractConfig logs unused messages, it
gets the value from the parsed configs. Since those are generated from the
ConfigDef, they value will not have been parsed or copied over from the
original map. This is especially confusing if you've explicitly set an option
to pass through to the serializers since you're always going to see these
warnings in your log.
The simplest patch would grab the original value from this.originals. But now
I'm not sure logging this makes sense at all anymore since configuring any
serializer that has options that aren't in ProducerConfig will create a
misleading warning message. Further, using AbstractConfig for your serializer
implementation would cause all the producer's config settings to be logged as
unused. Since a single set of properties is being used to configure multiple
components, trying to log unused keys may not make sense anymore.
> Logging of unused options always shows null for the value and is misleading
> if the option is used by serializers
> ----------------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-2026
> URL: https://issues.apache.org/jira/browse/KAFKA-2026
> Project: Kafka
> Issue Type: Bug
> Components: clients
> Affects Versions: 0.8.2.1
> Reporter: Ewen Cheslack-Postava
> Assignee: Ewen Cheslack-Postava
> Priority: Trivial
> Fix For: 0.8.3
>
>
> This is a really simple issue. When AbstractConfig logs unused messages, it
> gets the value from the parsed configs. Since those are generated from the
> ConfigDef, they value will not have been parsed or copied over from the
> original map. This is especially confusing if you've explicitly set an option
> to pass through to the serializers since you're always going to see these
> warnings in your log.
> The simplest patch would grab the original value from this.originals. But now
> I'm not sure logging this makes sense at all anymore since configuring any
> serializer that has options that aren't in ProducerConfig will create a
> misleading warning message. Further, using AbstractConfig for your serializer
> implementation would cause all the producer's config settings to be logged as
> unused. Since a single set of properties is being used to configure multiple
> components, trying to log unused keys may not make sense anymore.
> Example of confusion caused by this:
> http://mail-archives.apache.org/mod_mbox/kafka-users/201503.mbox/%3CCAPAVcJ8nwSVjia3%2BH893V%2B87StST6r0xN4O2ac8Es2bEXjv1OA%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
