...
The producer will have a DynamicProducerConfig
that will periodically fetch dynamic configs from the producer’s IO thread asynchronously. 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. It will use DescribeConfigsRequest
as the RPC, validate the dynamic configs returned in DescribeConfigsResponse
against the user provided configs, and reconfigure the client. This reconfiguration will be done by using a method in DynamicProducerConfig
that gets the current value of acks
. The dynamic acks
config will take precedence over user provided acks
config unless the user provided configs require acks
to be a certain value, such as enable.idempotence=true
. In this case the dynamic update will be ignored.
Consumer Changes
The consumer will have a DynamicConsumerConfig
that will periodically fetch dynamic configs from the consumer’s heartbeat thread asynchronously. 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. It will use DescribeConfigsRequest
as the RPC, validate the dynamic configs that are returned in DescribeConfigsResponse
against the user provided configs, and reconfigure the client by changing the session timeout and heartbeat interval in the GroupRebalanceConfig
. The dynamic configs will take precedence over user provided client configs.The GroupCoordinator
in the broker receives a group member’s session timeout upon the JoinGroupRequest
and stores this with the rest of the group member's metadata. This means that to dynamically configure a consumer’s session timeout, we must send a JoinGroupRequest
. Since this could trigger an expensive rebalance operation, we think that it would be best to delay the first JoinGroupRequest
until the first DescribeConfigsRequest
is made from the consumer. This will prevent an unnecessary JoinGroupRequest
when the consumer is discovering its dynamic configurations on startup. This initial DescribeConfigsRequest
will be done synchronously from the main thread of the AbstractCoordinator
. All subsequent RPCs for dynamic configs will be done asynchronously from the HeartbeatThread
of the AbstractCoordinator
GroupCoordinator
in the broker receives a group member’s session timeout upon the JoinGroupRequest
and stores this with the rest of the group member's metadata. This means that to dynamically configure a consumer’s session timeout, we must send a JoinGroupRequest
. Since this could trigger an expensive rebalance operation, we think that it would be best to delay the first JoinGroupRequest
until the first DescribeConfigsRequest
is made from the consumer. This will prevent an unnecessary JoinGroupRequest
when the consumer is discovering its dynamic configurations on startup. This initial DescribeConfigsRequest
will be done synchronously from the main thread of the AbstractCoordinator
. All subsequent RPCs for dynamic configs will be done asynchronously from the HeartbeatThread
of the AbstractCoordinator
.
There will be a DynamicConsumerConfig
that will periodically fetch dynamic configs. 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. It will use DescribeConfigsRequest
as the RPC, validate the dynamic configs that are returned in DescribeConfigsResponse
against the user provided configs, and reconfigure the client by changing the session timeout and heartbeat interval in the GroupRebalanceConfig
. The dynamic configs will take precedence over user provided client configs.
Admin Client Changes
The methods describeConfigs
and incrementalAlterConfigs
in the admin client 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.
...