Hangleton commented on PR #13619: URL: https://github.com/apache/kafka/pull/13619#issuecomment-1516151278
Hi, Radim, Thanks for the PR. This would definitely need a KIP. I am quite curious about the use cases driving this. Some problems I see with the approach: - Apache Kafka brokers have an extensive amount of states and cached metadata at any given time. This state is often not applicable upon application restart. For instance, by restoring the previous state of the application, replica states, leader epochs, consumer ids would be stale. This list is far from exhaustive. - Active connections are used by the controller and quorum to determine the liveness of a broker. Once these connections are closed, the broker is reportedly dead and any new process of the broker comes with a new identity either in the form of a Zookeeper session or broker incarnation id. This conflicts with the re-use of the state hold by a defunct broker process. - A critical part of Apache Kafka's startup process is to verify the integrity of the data stored on the brokers. Based on on the applicative checkpoints read upon start, Kafka can perform index and state reconstruction by scanning replica logs. Without this, we would remove the current integrity guarantees which the recovery path provides at startup. Unless the broker needs to take the recovery actions stated above, start-up of a broker is usually fairly fast, a matter of seconds in common use cases. What pushes the need for the feature involved in this PR? -- 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
