[
https://issues.apache.org/jira/browse/KAFKA-20835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18099056#comment-18099056
]
Matthias J. Sax commented on KAFKA-20835:
-----------------------------------------
That would for sure be an improvment, but it seems, it would be even better if
we only validate the configs changed by the admin RPC, and not fail for any
unchanged configs even if they are invalid? This way, if an RPC only makes
valid changes, it would just go through. Why fail if some other config is
invalid? It has nothing to do with the currently processed RPC.
> Group-level alter-config RPC fails, if single group config is invalid
> ---------------------------------------------------------------------
>
> Key: KAFKA-20835
> URL: https://issues.apache.org/jira/browse/KAFKA-20835
> Project: Kafka
> Issue Type: Bug
> Components: group-coordinator
> Reporter: Matthias J. Sax
> Priority: Minor
>
> ControllerConfigurationValidator gets the full post-alter override map, not
> just the altered keys. So if a broker bound is narrowed after an override was
> set, GroupConfig.validate() rejects the stale value on every later alter –
> even one that doesn't touch it.
> Repro: set consumer.session.timeout.ms=90000 on a group, restart controller
> with group.consumer.max.session.timeout.ms=60000, then try to alter
> consumer.heartbeat.interval.ms on the same group -> INVALID_CONFIG on the
> session timeout.
> Impact: the group is stuck until the stale key is fixed or deleted.
> Validation is all-or-nothing per resource, and throws on the first violation,
> so multiple stale keys must all be repaired in one request, discovered one
> error at a time.
> It seems LogConfig may have a similar issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
