What is the control-plane listener (control.plane.listener.name), why was it introduced, and how does it differ from data-plane listeners and the KRaft controller listener?

**Background — control plane vs data plane.** Kafka request traffic splits conceptually into two planes. The **data plane** is high-volume client and replication traffic (produce, fetch, replica fetch). The **control plane** is the relatively rare but **latency-critical** cluster-management traffic: in ZooKeeper-mode the elected **controller** sends brokers requests like **LeaderAndIsr** (who leads which partition), **UpdateMetadata** (cluster state), and **StopReplica**. These drive failover and rebalancing — if they're delayed, the cluster is slow to recover from broker failures. **The problem KIP-291 solved.** Originally all requests — data and control — flowed through the same listener, the same socket-server acceptor, and the same shared request-handler queue. Under heavy data load, control requests could **queue behind** thousands of produce/fetch requests, delaying critical leadership and ISR updates and prolonging unavailability during failover. **The fix — `control.plane.listener.name`.** You designate one named listener as the control-plane listener. The controller then uses *that* listener to reach brokers, and the broker processes those requests on a **dedicated, separate thread and queue**, isolated from data-plane contention. Example: ``` listeners=CONTROLLER://0.0.0.0:9093,INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9094 listener.security.protocol.map=CONTROLLER:SSL,INTERNAL:SSL,EXTERNAL:SASL_SSL control.plane.listener.name=CONTROLLER inter.broker.listener.name=INTERNAL ``` Now controller-to-broker requests ride the CONTROLLER listener (here mTLS) and never compete with data traffic. **Three distinct listener roles — don't conflate them:** 1. **Data-plane / client listeners** — produce/consume and replica-fetch data traffic. 2. **Control-plane listener (`control.plane.listener.name`)** — controller→broker control requests, **ZooKeeper-mode** feature from KIP-291. Optional; if unset, control traffic shares the inter-broker listener. 3. **KRaft controller listener (`controller.listener.names`)** — in **KRaft** mode there is no ZooKeeper; cluster metadata lives in a Raft-replicated metadata log managed by a **controller quorum**. `controller.listener.names` defines the listener(s) the controller quorum uses for Raft voting and metadata-log replication. This is a *different mechanism* from KIP-291's control-plane listener — KRaft replaced the controller-pushes-RPCs model with brokers pulling metadata-log records, though brokers still maintain a connection to the active controller. **Why a principal cares:** - **Availability:** Isolating control traffic shortens failover time under load — a real SLO lever. - **Security segmentation:** The control path can be pinned to a trusted network and stronger protocol (mTLS), separate from client exposure. - **Migration awareness:** As clusters move from ZooKeeper to KRaft, `control.plane.listener.name` (KIP-291) becomes irrelevant and `controller.listener.names` takes over; architects must not carry the old config into KRaft configs or assume the same semantics. **Edge cases:** - Setting `control.plane.listener.name` requires that listener to exist and be mapped; it must be reachable from the controller broker. - It should not equal the inter-broker listener if isolation is the goal (sharing defeats the purpose). - It is unrelated to client request quotas/throttling, though both target contention.