Mailing-List: contact jira-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@kafka.apache.org
Date: Mon, 17 Jul 2017 15:55:00 +0000 (UTC)
From: "Stevo Slavic (JIRA)" <jira@apache.org>
To: jira@kafka.apache.org
Message-ID: <JIRA.13072979.1495071031000.263688.1500306900043@Atlassian.JIRA>
In-Reply-To: <JIRA.13072979.1495071031000@Atlassian.JIRA>
References: <JIRA.13072979.1495071031000@Atlassian.JIRA> <JIRA.13072979.1495071031112@jira-lw-us.apache.org>
Subject: [jira] [Commented] (KAFKA-5274) Review and improve AdminClient
 Javadoc for the first release (KIP-117)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 17 Jul 2017 15:55:10 -0000


    [ https://issues.apache.org/jira/browse/KAFKA-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089993#comment-16089993 ] 

Stevo Slavic commented on KAFKA-5274:
-------------------------------------

Sorry for late feedback, missed that this client was being exposed and included in 0.11.

From JavaDoc it's not clear with which exceptions will returned Futures fail/complete in different error cases.
E.g. I wanted to migrate logic using old topic deletion in Scala AdminUtils to new Java AdminClient and it's not clear whether future will complete with success or fail with TopicDeletionInProgressException if topic deletion has already been requested.

Also, it seems cumbersome to force collections e.g. set of topics to be deleted, and map in response when all I want to do is create single topic or delete single topic. Please overload methods to support single item ops, wrap/reuse boilerplate code internally.

Was thinking of using {{all}} instead of {{values}} to avoid dealing with Map when deleting just single topic, but then was not sure what will be exception in failure even if just single delete is issued - will it be some generic exception saying that some of the deletion request failed, and it won't even have any of the exceptions of individual deletion requests, or will the all future on failure include just some exception from any (first) of the failed deletions.

In general, are there plans to get away from java.util Future and use [Flow once available in Java 9|http://cs.oswego.edu/pipermail/concurrency-interest/2015-January/013641.html]? Future API in Java as it is now is horrible. What was rational to use Java's Future in client API? I don't see it in KIP-4 wiki. Maybe it's broader decision for all Kafka Java APIs. I'd prefer RxJava implementation and http://www.reactive-streams.org/ interfaces over "standard" Future API anytime in Java 8, even Java itself is going in that direction.

> Review and improve AdminClient Javadoc for the first release (KIP-117)
> ----------------------------------------------------------------------
>
>                 Key: KAFKA-5274
>                 URL: https://issues.apache.org/jira/browse/KAFKA-5274
>             Project: Kafka
>          Issue Type: Sub-task
>            Reporter: Ismael Juma
>            Assignee: Ismael Juma
>             Fix For: 0.11.0.0, 0.11.1.0
>
>
> Once all the AdminClient pieces are in, we should take a pass at the Javadoc and improve it wherever possible.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)