Page History

...

Previously, the broker would only send its ID to the controller using the ZK watch mechanism. This meant Since only the broker ID was sent (and not the broker epoch) the controller needed to probe the broker to learn its true state. Theoretically, a broker could have been repaired and restarted before the controller had to send a LeaderAndIsr request to the brokers in order to learn which replicas were offline. Using a more direct approach as proposed here, the controller can update its view of the replica's state immediately and react accordingly.a chance to react to the event. The controller would probe the brokers using LeaderAndIsr requests to learn what state the replicas were in. In this proposal, we now include the broker ID and epoch in the request, so the controller can safely update its internal replica state based on the request data. If the broker had in fact been restarted since sending the ReplicaStateEvent, the controller would be gated by the broker epoch and would not take any action. 

RPC semantics

• The EventType field in the request is will only support the value 1 which will represent "offline"
• The EventReason field is an optional textual description of why the event is being sent
• If no Topic is given, it is implied that all topics on this broker are being indicated
• If a Topic and no partitions are given, it is implied that all partitions of this topic are being indicated
• LeaderEpoch is optional and is not validated for the "offline" event type

...