This is an automatically generated e-mail. To reply, visit:
This comment is misleading since the exception complains about an existing topic.
Also, not sure why this should be a RetriableException since the only way to get out of this is to delete the topic, which is an admin operation.
How about renaming this to TopicCreationFailedException?
It would also be helpful for the comment to provide details about which kind of failures can occur during topic creation.
The doc here is incorrect.
The doc string for "topics" can be improved -> "The list of topics to be created"
Why is this one required if we already have one of these defined under clients?
we cannot have metadata request handling access zookeeper. In the past, we've gotten bitten by the kind of slowdown the zk access causes.
Besides, I think this check is not required. In the case that the metadata cache is not updated but the topic is in zookeeper, we could just return UnknownTopicOrPartitionCode and explicitly state that create topic is not a sync operation.
Also I think we have to maintain the old config behavior for backwards compatibility and prevent making any changes to the old producer. We can auto.create off by default. That way folks using the old producer can continue using auto create as is. And those using new producer will have it turned off. I'm guessing we have to maintain this behavior at least for 1-2 releases.
Same comment as in SimpleConsumerShell
I think there are 2 kinds of error messages that could be useful depending on whether the topic exists or the topic metadata was incomplete/incorrect.
I think it is useful to give an explicit error message saying "The topic %s doesn't exist" in case the error code is UnknownTopic...
- Neha Narkhede
On Aug. 13, 2014, 1:09 a.m., Sriharsha Chintalapani wrote: