jiafu1115 commented on code in PR #20203:
URL: https://github.com/apache/kafka/pull/20203#discussion_r2462800981
##########
core/src/main/scala/kafka/server/BrokerServer.scala:
##########
@@ -591,6 +600,15 @@ class BrokerServer(
"all of the SocketServer Acceptors to be started",
enableRequestProcessingFuture, startupDeadline, time)
+ brokerReadyCallbacks.foreach { callback =>
+ try {
+ callback.onBrokerReady()
Review Comment:
@chia7712 It is similar with initial delay but the delay value is not fixed
one. New introduced configure's issue is that the initial delay is a fixed
value — Thus, it should varies depending on the startup duration of different
Kafka clusters. The delay should be greater than or equal to the startup time
to avoid failed retries when metadata is stored as a topic in the local cluster.
For example:
Cluster A takes about 10 seconds to start up, so the initial delay should be
greater than 10 seconds.
Cluster B takes about 10 minutes to start up, so the initial delay should be
greater than 10 minutes.
The problem is that Cluster A’s startup time may increase as the amount of
topic data grows, which means you’ll need to update the configuration
repeatedly. Alternatively, you can set a very large value to ensure the
broker’s startup time never exceeds it. That’s the workaround I’m currently
using — I’ve set the configuration to 20 minutes which also cover the initial
configure if introduced.
--
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]
