mumrah commented on code in PR #15744:
URL: https://github.com/apache/kafka/pull/15744#discussion_r1569214270
##########
core/src/main/scala/kafka/server/KafkaApis.scala:
##########
@@ -3003,9 +3008,10 @@ class KafkaApis(val requestChannel: RequestChannel,
}
}
+ // Forwarding has not happened yet, so handle both ZK and KRaft cases here
if (remaining.resources().isEmpty) {
sendResponse(Some(new IncrementalAlterConfigsResponseData()))
- } else if ((!request.isForwarded) && metadataSupport.canForward()) {
+ } else if ((!request.isForwarded) && metadataSupport.canForward() &&
isKRaftController) {
Review Comment:
It's kind of inconsequential that the ZK controller was handling a forwarded
IncrementalAlterConfigs. All of the IAC handling is done in KafkaApis and never
even checks if it's the active controller.
Basically when handling the broker-specific configs, the broker handling the
forwarded request (i.e., the ZK controller) would see that the broker ID didn't
match and fail.
TBH, a better fix would be to always forward to the ZK controller, and
update the ZK brokers to react to the ZNode change event to process BROKER and
BROKER_LOGGER changes. But that's a much bigger change :-/
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
