...
UNKNOWN_TOPIC_OR_PARTITION (3) If the topic or partition doesn't exist on any broker in the cluster. Note that the use of this code is not precisely the same as it's usual meaning of "This server does not host this topic-partition".
NOT_CONTROLLER (41) If the request is sent to a broker that is not the controller for the cluster.
- REPLICA_LEADER_ELECTION_IN_PROGRESS (new) if elections are already in progress. The request can be retried at a later time.
- TOPIC_AUTHORIZATION_FAILED (29) If the user didn't have Alter access to the topic.
NONE
(0) The election has successfully been started.
Broker-side election algorithm
The broker-side handling of ElectPreferredReplicaLeaderRequest
will be somewhat different than currently:
- On receipt of
ElectPreferredReplicaLeaderRequest
the controller will atomically check-and-set a flag (to prevent concurrent elections) then enqueue aPreferredReplicaLeaderElection
with theControllerManager
- The controller will when await completion of the
PreferredReplicaLeaderElection
, with a timeout. - When processing the
PreferredReplicaLeaderElection
the controller will clear the flag. - Successful or timed-out completion of the
PreferredReplicaLeaderElection
will result in aElectPreferredReplicaLeaderResponse
being returned to the client
(The flag will also be checked-and-set when handling a change of the /admin/preferred_replica_election
znode, via the existing --zookeeper
-supporting code)
This change means that the ElectPreferredReplicaLeaderResponse
is sent when the election is actually complete, rather than when the /admin/preferred_replica_election
znode has merely been updated. Thus if the election fails, the ElectPreferredReplicaLeaderResponse
's error_code
will provide a reason.
When support for the --zookeeper
option is eventually removed, the need for the /admin/preferred_replica_election
znode will disappear and consequently the code managing it will be removed.
Compatibility, Deprecation, and Migration Plan
...