kamalcph commented on code in PR #20203:
URL: https://github.com/apache/kafka/pull/20203#discussion_r2480258894
##########
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:
Problem Summary:
When the broker starts, then the TBRLMM instantiates the Admin, Producer,
and Consumer to sync-up the metadata. During this time, if the broker is not
ready to accept the requests, then TBRLMM might timeout (2 mins) and crashes
the broker.
Default config for `remote.log.metadata.common.client.boostrap.servers`
would be localhost:9092 (or) localhost:[securePort]
1. If the user configures the cluster DNS as value, then there would be no
issues. Since if any one node in the cluster is ready to process the requests,
then the Admin/Producer/Consumer will work as expected.
2. We cannot configure another host as the node might get replaced and the
config value becomes stale.
3. The `brokerReady` callback is required only for connecting to local node.
The existing config (remote.log.metadata.initialization.retry.max.timeout.ms)
that delays the initialization may not be effective as the broker start-up time
can differ based on workload and graceful / ungraceful shutdown.
So, the workaround looks good to me.
> this change is not a public Kafka API
The `BrokerReadyCallback` interface is not part of public API, then should
this be moved away from `org.apache.kafka.server.common` package server-common
to storage module?
--
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]
