Thanks for the KIP Ryan. Here are some of my observations. 1. > We will also be adding a new client configuration enable.dynamic.config to > both the producer and consumer that will be true by default so that the user > has the option to disable this feature.
How about? "The Java producer and consumer clients will have a new configuration property `enable.dynamic.config` with a default value of `true`. When this configuration property is true the proposed producer and consumer changes in this KIP are enabled." You can go into more details in the producer and consumer changes section. 2. > ... the following order of precedence: I would be a bit more specific here. For example, when the broker handles `DescribeConfigRequest`, it will first use the client config key-values store in `/config/clients/<default>`. If there is a matching `config/clients/<client-id>` then any client config key-value in the matching znode will override the key-values found in `config/clients/<default>`. 3. > These dynamic configs will be stored in zookeeper as the children of the > ZNode /config/clients How are the client dynamic config key-values stored here? I assume that they are updated based on the content of `IncrementalAlterConfigsRequest`. When is `.../<default>` updated? When is `.../<client-id>` updated? 4. > The interval on which dynamic configs are fetched will be the same amount of > time as the interval for MetadataRequest which is currently five minutes. Will this be hard-coded to 5 minutes? Or is this KIP going to use the same frequency as the producer config `metadata.max.age.ms`? Same question for the "Consumer Changes" section. 5. The Consumer Changes section mentions that the consumer would ask for the dynamic configuration from the broker before joining the group coordinator. This makes sense to me. How about the producer? Should the producer also describe the dynamic configuration before sending acks for the "produce" messages? 6. For the Admin Client Changes section, how are DescribeConfigs and IncrementalAlterConfig requests going to get routed by the client to the different brokers in the cluster? 7. You mentioned that the producer and the consumer will validate the keys and values received from the broker through DescribeConfigs. Will the ConfigCommand validate any of the keys or values specified in --add-config and --delete-config? Will the broker validate any of the keys or values received in the IncrementalAlterConfigs? 8. In rejected ideas the KIP says: > This might make sense for certain configurations such as acks, but does not > for others such as timeouts. I don't think it makes sense even for acks since the clients of the Java Producer assume that all of the produce messages are sent with the same ack value. -- -Jose
