이선민 created KAFKA-21433:
---------------------------
Summary: Group config overrides are validated against the
controller's group bounds but clamped against the broker's
Key: KAFKA-21433
URL: https://issues.apache.org/jira/browse/KAFKA-21433
Project: Kafka
Issue Type: Bug
Components: controller, group-coordinator
Affects Versions: 4.4.0, 4.3.0
Reporter: 이선민
Attachments: run.sh, summary.md
When the controllers run as separate processes, an override set with
kafka-configs.sh --entity-type groups is validated by the controller against
the group bounds in the controller's own config, but it is clamped by the
broker against the broker's bounds. If the two sets of bounds differ, an
override can be clamped from the moment it is set. The reproduction below does
not change any bounds after the override is set.
The validation happens in ControllerConfigurationValidator
(GroupConfig.validate with kafkaConfig.groupCoordinatorConfig).
ControllerServer passes it sharedServer.brokerConfig, which SharedServer builds
from the same process's properties as controllerConfig, so on a dedicated
controller these are the controller's own group bounds. On the broker,
GroupConfig clamps the override using the broker's GroupCoordinatorConfig
bounds.
I reproduced this on trunk at 601492157a. Code inspection of the 4.3.0 and
4.4.0 tags also shows controller-local bounds validation and broker-local
clamping; I have not run the reproduction on those releases.
*Reproduction* (trunk 601492157a, one controller and one broker, script
attached)
* Controller: no group.consumer.* settings, so the default bounds 45000 to
60000 apply.
* Broker:
{noformat}
group.consumer.min.session.timeout.ms=20000
group.consumer.session.timeout.ms=25000
group.consumer.max.session.timeout.ms=30000
{noformat}
Results:
# {{--alter --add-config consumer.session.timeout.ms=45000}} succeeded, and the
broker logged right away:
{noformat}
The group config 'consumer.session.timeout.ms' for group 'g1' has value 45000
which exceeds the broker's allowed maximum 30000. The effective value will be
capped to 30000.
{noformat}
# DescribeConfigs returned 45000 (DYNAMIC_GROUP_CONFIG).
# A consumer (group.protocol=consumer) was fenced for session expiry
approximately 27.8 seconds after SIGKILL, consistent with the broker's logged
effective timeout of 30000 ms.
# 25000, which is inside the broker's bounds, was rejected:
{noformat}
consumer.session.timeout.ms must be in the range 45000 to 60000 inclusive.
{noformat}
With these configs, the two ranges do not overlap: every accepted override of
consumer.session.timeout.ms is clamped by the broker, and every value within
the broker's allowed range is rejected by the controller.
The same validation path covers the other bounded group configs (share and
streams as well), but I only reproduced it with consumer.session.timeout.ms.
*Question*
As far as I can see, the docs do not say that the group.* bounds must also be
set on the controllers. Are operators expected to configure matching group
bounds on controllers and brokers? If not, how should group override validation
account for the bounds enforced by brokers?
Found while investigating configured versus effective group values for KIP-1389
(KAFKA-20848). It is related to KAFKA-20835, which is about stale overrides
after the bounds are narrowed; here the cause is that validation and clamping
read their bounds from different processes.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
