[
https://issues.apache.org/jira/browse/KAFKA-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089993#comment-16089993
]
Stevo Slavic edited comment on KAFKA-5274 at 7/18/17 5:34 AM:
--------------------------------------------------------------
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 with a specific exception 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.
was (Author: sslavic):
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)
