hachikuji commented on code in PR #11951:
URL: https://github.com/apache/kafka/pull/11951#discussion_r862003291
##########
core/src/main/scala/kafka/server/BrokerLifecycleManager.scala:
##########
@@ -333,7 +353,11 @@ class BrokerLifecycleManager(val config: KafkaConfig,
}
private def sendBrokerHeartbeat(): Unit = {
- val metadataOffset = _highestMetadataOffsetProvider()
+ val metadataOffset = if (readyToUnfence) {
Review Comment:
@dengziming Yeah, I was considering a second field as well. That would allow
a startup transition looking something like this:
1. Broker catches up: fetch_offset=N, publish_offset=0
2. Controller returns is_caught_up=true, is_fenced=true
3. Broker begins publishing: fetch_offset=N, publish_offset=N
4. Controller returns is_caught_up=true, is_fenced=false
Basically the controller uses fetch_offset to tell whether the broker is
caught up and it uses publish_offset to tell whether it should be unfenced. I
guess the main advantage is that it gives us some more protection from exposing
old metadata when brokers rejoin the cluster. Or at least we can put a time
bound on the staleness of the exposed metadata. The value of this may be a bit
limited though since we don't do self-fencing.
@cmccabe What do you think?
--
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
