Hi all, I updated KIP-1329 based on review feedback.
Thread safety. My first email said the POC confirmed thread safety. That was wrong. Selector.channels() copies a plain HashMap that the processor thread changes without a lock, so reading it from the request handler thread is not safe. In the revised design, processor threads write connection metadata to a shared concurrent registry, and the handler reads only the registry. ConnectedSince. This field is now populated in version 0. It is set when the connection is registered, not deferred to a follow-up. Broker attribution. The response now carries NodeId, and the Admin result exposes per-broker futures (byBrokerId(), as in ListTransactionsResult). A broker that does not respond shows up as a failure, not as an empty result. KIP: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1329%3A+ListClientConnections+Admin+API The POC still uses the old approach. I will update it to the registry design. Feedback welcome, especially on the registry design. Thanks, Mehari Get Outlook for Mac<https://aka.ms/GetOutlookForMac> From: Beyene, Mehari <[email protected]> Date: Thursday, May 28, 2026 at 10:06 AM To: [email protected] <[email protected]> Subject: Re: Subject: [DISCUSS] KIP-1329: ListClientConnections Admin API Hi all, Gentle bump on this proposal. Would appreciate any feedback on the approach — particularly the response schema and filter design. Thanks, Mehari On 5/21/26, 4:18 PM, "Beyene, Mehari" <[email protected] <mailto:[email protected]>> wrote: CAUTION: Email security compliance checks failed. Do not reply to this email, click links or open attachments unless you can confirm the sender. For more information, search for DMARC on Amazon's IT Portal at it.amazon.com Hi all, I'd like to propose KIP-1329: a new broker-level admin API that lists currently authenticated client connections. * KIP: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1329%3A+ListClientConnections+Admin+API <https://cwiki.apache.org/confluence/display/KAFKA/KIP-1329%3A+ListClientConnections+Admin+API> * JIRA: https://issues.apache.org/jira/browse/KAFKA-20526 <https://issues.apache.org/jira/browse/KAFKA-20526> * POC: https://github.com/apache/kafka/compare/trunk...mehbey:kafka:kip-1329-list-client-connections-poc <https://github.com/apache/kafka/compare/trunk...mehbey:kafka:kip-1329-list-client-connections-poc> The problem: Kafka has no way to answer "which principals are connected right now?" MySQL has SHOW PROCESSLIST, PostgreSQL has pg_stat_activity, RabbitMQ has /api/connections — Kafka has nothing. This matters most during security incidents (compromised credentials) and credential rotation, where operators need to verify active connections without restarting brokers. The broker already holds all the data in memory (KafkaPrincipal on every KafkaChannel) — it's just not exposed through any external interface. The proposal adds a ListClientConnections RPC (API key 93) that returns: principal, client address/port, listener, security protocol, and client software info. It requires DESCRIBE on CLUSTER and supports optional filters. A working POC validates the approach against trunk — thread safety, API registration, and connection enumeration all work as expected. Looking forward to your feedback. Full details in the KIP. Thanks, Mehari
