[
https://issues.apache.org/jira/browse/KAFKA-18212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904785#comment-17904785
]
Chia-Ping Tsai commented on KAFKA-18212:
----------------------------------------
we can remove the following code as a simple solution
```
// Rebootstrap if needed and configured.
if (metadataRecoveryStrategy == MetadataRecoveryStrategy.REBOOTSTRAP
&& !leastLoadedNode.hasNodeAvailableOrConnectionReady()) {
log.info("[CHIA] maybeUpdate");
rebootstrap(now);
leastLoadedNode = leastLoadedNode(now);
}
```
that is fine as `NetworkClient#handleRebootstrap` will check the rebootstrap
later
> Rolling-upgrade broker causes unnecessary re-balance on classic consumer
> ------------------------------------------------------------------------
>
> Key: KAFKA-18212
> URL: https://issues.apache.org/jira/browse/KAFKA-18212
> Project: Kafka
> Issue Type: Bug
> Reporter: Chia-Ping Tsai
> Assignee: Chia-Ping Tsai
> Priority: Blocker
>
> KAFKA-17885 sets the rebootstrap policy by default and introduces
> metadata.recovery.rebootstrap.trigger.ms to control the rebootstrap interval.
> However, DefaultMetadataUpdater#maybeUpdate [0] does not honor
> metadata.recovery.rebootstrap.trigger.ms and triggers a rebootstrap when no
> node is available. This causes the metadata to be reset during rolling
> upgrades of brokers, leading the classic consumer [1] to send a rejoin
> request due to the metadata change.
> [0]
> https://github.com/apache/kafka/blob/7591868aead54fff7d5e8a44c5e06746ed34866b/clients/src/main/java/org/apache/kafka/clients/NetworkClient.java#L1230
> [1]
> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerCoordinator.java#L883
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
