Page History

...

The handlers in the broker for DescribeConfigs and IncrementalAlterConfigs will both be extended to support the CLIENT resource type. The handler in the broker for AlterConfigs will return an InvalidRequest error code if this new resource type is used in a AlterConfigsRequest. This is because we are using IncrementalAlterConfigs in kafka-configs.sh to alter these dynamic configs and will not be adding a support for the CLIENT resource type in AlterConfigs.

...

The methods describeConfigs and incrementalAlterConfigs in the admin client with will now be able to use the CLIENT resource type to describe and alter dynamic client configs. This is a byproduct of adding the CLIENT resource type to ConfigResource as outlined in the public interfaces section, and of adding handlers for this resource type in the broker as outlined in the broker changes section.

...

We can describe these configs the same way that client quotas are described with the clients entity type. To make this possible we are will be sending a DescribeConfigsRequest and a  as well as the DescribeClientQuotasRequest:

...

• Introducing new entity types for kafka-configs.sh that producers and consumers can associate themselves with. This would make the tool more cumbersome to use and it is most intuitive that client configurations be dynamically altered with the clients entity type.

• Use the <user/client-id> hierarchy implemented for client quotas in KIP-55 and extended for the admin client in KIP-546. If we already had APIs for non-quota configs where this hierarchy existed, it would have been worthwhile to allow this for consistency. However, quota APIs are different and quotas are inherently hierarchical, so it seems reasonable to use a different approach here.

• Sending user-provided client configuration values to the broker on startup. The user-provided client configurations are not needed by the broker to send back dynamic configurations. DescribeConfigsRequest does not have a field for config values so a new message format would need to be created.

• Making certain client configurations topic level configurations on the broker

  • This might make sense for certain configurations such as acks, but does not for others such as timeouts.

  • The semantic for the ProduceRequest API would be undefined since we would not receive a response with an offset for the ProduceRequests with acks=0.

  • If this were implemented for acks there would also be quite a bit of overhead associated with extra round trips since the RecordAccumulator sends batches that may contain records from multiple topics. If these topics have different acks configurations the records would need to be sent in different batches based on the acks value.

  • For example, if a producer is consistently producing to 2 different topics and one is configured as acks=0 while the other is acks=-1. This would require twice the amount of round trips to produce the same number of messages. This is the main reason that acks will remain a client configuration.