...

The user should be able to see what dynamic configs are supported for each application. However, clients may not necessarily support the same dynamic configs even if they that are using the same <user, client-id> entity may not necessarily support the same dynamic configs. A partial flawed solution to this is to store a map of client software names and versions ClientInformation to lists of supported configs in each <user, client-id> entity config. The big flaw in problem with storing the registration alongside configs is that the entity config could be updated concurrently if multiple clients with the same entity names register at the same time.

A better alternative to this solution is to store config registrations in an internal topic and perform ad hoc aggregations on the data registrations for a particular entity to gather compatibility information . For example, all versions of clients that registered with an entity along with the supported configs for each version of client could be aggregated and returned to the user in the DescribeClientConfigsResponseabout clients that are tied to that entity. The Java producer and consumer clients can register the configs they they support and the broker can tie the registered keys to the serialized ClientInformation from the RequestContextwrite a key-value pair to an internal topic where the key is the <user, client-id> entity and the value is ClientVersion along with the list of supported configs. This allows compatibility information to be displayed to the user . As and as long as the user knows what version of client each application is using, they will know which applications will be affected by each dynamic config. For example, all versions of clients that registered with an entity along with the supported configs for each version of client could be aggregated and returned to the user in the DescribeClientConfigsResponse. 

Public Interfaces

...

Admin Client Changes

...