gabriellefu commented on code in PR #23439: URL: https://github.com/apache/kafka/pull/23439#discussion_r3992549061
########## docs/getting-started/upgrade.md: ########## @@ -56,6 +56,7 @@ type: docs * Controllers can now be unregistered from the cluster metadata. A new `kafka-cluster.sh unregister-controller` command and a `--unregister` flag on `kafka-metadata-quorum.sh remove-controller` are provided, backed by the new `Admin#unregisterController` API and the new `UnregisterController` RPC. This introduces the error code `CONTROLLER_ID_NOT_REGISTERED` (136) and requires metadata version `4.4-IV2` (`IBP_4_4_IV2`). For further details, please refer to [KIP-1312](https://cwiki.apache.org/confluence/spaces/KAFKA/pages/406623954/KIP-1312+Support+unregistering+controllers). * A new client configuration, `bootstrap.resolve.timeout.ms`, controls how DNS resolution of `bootstrap.servers` is performed. The default value of `0` preserves the historical synchronous behavior. Setting a positive value opts into asynchronous bootstrap resolution: the client constructor returns immediately, `NetworkClient` retries DNS resolution up to the configured timeout, and failures are surfaced later as `BootstrapResolutionExceptions` from subsequent API calls. This failure is unrecoverable: once raised, the exception is re-thrown by every API call until the client is closed and re-created after fixing the underlying DNS or `bootstrap.servers` configuration. Both asynchronous bootstrap resolution (enabled by setting `bootstrap.resolve.timeout.ms` to a positive value) and `BootstrapResolutionException` are evolving features and may undergo compatibility-breaking changes in a minor release. For further details, please refer to [KIP-909](https://cwiki.apache.org/confluence/ x/MJtbDg). Note that Kafka Streams and Kafka Connect do not support asynchronous bootstrap resolution yet: for every client they create internally, `bootstrap.resolve.timeout.ms` is forced to `0` and a user-supplied positive value is ignored with a warning. * For tiered-storage topics, time-based local retention (`local.retention.ms`) now uses a segment's last modified time as the age anchor when the segment's largest record timestamp is in the future. Previously such a segment was never removed by time-based retention (its future timestamp kept it perpetually within the retention window) and was only reclaimed once `local.retention.bytes` was breached, even though it had already been uploaded to remote storage. For further details, please refer to [KAFKA-20609](https://issues.apache.org/jira/browse/KAFKA-20609). + * `group.consumer.assignors` now fails broker startup with a `ConfigException` if two configured entries resolve to the same assignor name, or if a custom assignor's name collides with a built-in assignor's name. Previously such configurations passed startup validation but could cause the group coordinator to fail later at runtime. For further details, please refer to [KAFKA-20843](https://issues.apache.org/jira/browse/KAFKA-20843). Review Comment: thanks, I have updated here and mention it only change the behavior of the collide of build-in assignor. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
