...

This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state:  Under Discussion  Discarded

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread] 

JIRA: here 

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Currently AdminClient supports describeTopics(Collection<String> topicNames) method API for describing topics and listTopics() API for listing topic name listingnames.
To describe all topics, users currently we need to use listTopics() to get all topic names and pass supply the name list to describeTopics. 

 In large clusters, the MetadataResponse can be large and sending multiple MetadataRequests can be inefficient.

Since "describe all topics" is a common operation, We propose to add describeTopics() method API to get all topic descriptions in single call.
This will be simple to use and avoids additional metadata requests.

Public Interfaces

...

Briefly list any new interfaces that will be introduced as part of this proposal or any existing interfaces that will be removed or changed. The purpose of this section is to concisely call out the public contract that will come along with this feature.

A public interface is any change to the following:

• Binary log format

• The network protocol and api behavior

• Any class in the public packages under clientsConfiguration, especially client configuration

  • org/apache/kafka/common/serialization

  • org/apache/kafka/common

  • org/apache/kafka/common/errors

  • org/apache/kafka/clients/producer

  • org/apache/kafka/clients/consumer (eventually, once stable)

• Monitoring

• Command line tools and arguments

• Anything else that will likely break existing users in some way when they upgrade

Proposed Changes

...

API Changes

We will introduce new API methods to AdminClient to describe all topics. 

/**
 * Describe all topics in the cluster, with the default options.
 */
public DescribeAllTopicsResult describeTopics() {
    return describeTopics(new DescribeTopicsOptions());
}

/**
 * Describe all topics in the cluster.
 *
 * @return                  The DescribeAllTopicsResult.
 */
public abstract DescribeAllTopicsResult describeTopics(DescribeTopicsOptions options);

New result class "DescribeAllTopicsResult" will be added.

/**
 * The result of the {@link KafkaAdminClient#describeTopics()} call.
 */
public class DescribeAllTopicsResult {
    private final KafkaFuture<Collection<TopicDescription>> future;

    DescribeAllTopicsResult(KafkaFuture<Collection<TopicDescription>> future) {
        this.future = future;
    }

    public KafkaFuture<Collection<TopicDescription>> value() {
        return future;
    }
}

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?
• If we are changing behavior how will we phase out the older behavior?
• If we need special migration tools, describe them here.
• When will we remove the existing behavior?

Rejected Alternatives

...

• There won’t be any compatibility issues