[
https://issues.apache.org/jira/browse/KAFKA-4675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833336#comment-15833336
]
huxi edited comment on KAFKA-4675 at 1/22/17 7:26 AM:
------------------------------------------------------
Failed to reproduce this issue with snippet below:
{code}
val zkUtils = ZkUtils("localhost:2181", 30000, 30000, false)
AdminUtils.deleteTopic(zkUtils, "old-topic")
AdminUtils.createTopic(zkUtils, "new-topic", 1, 1)
{code}
After running the code above, topic "new-topic" will be created. Seems
subsequent CreateTopic command has still been invoked. [~guozhang] Does the
code reflect the way you run into this problem?
was (Author: huxi_2b):
Failed to reproduce this issue with snippet below:
{code}
val zkUtils = ZkUtils("localhost:2181", 30000, 30000, false)
AdminUtils.deleteTopic(zkUtils, "old-topic")
AdminUtils.createTopic(zkUtils, "new-topic", 1, 1)
{code}
After running the code above, topic "new-topic" will be created. Seems
subsequent CreateTopic command has still been invoked. Does the code reflect
the way you run into this problem?
> Subsequent CreateTopic command could be lost after a DeleteTopic command
> ------------------------------------------------------------------------
>
> Key: KAFKA-4675
> URL: https://issues.apache.org/jira/browse/KAFKA-4675
> Project: Kafka
> Issue Type: Bug
> Reporter: Guozhang Wang
> Labels: admin
>
> This is discovered while investigating KAFKA-3896: If an admin client sends a
> delete topic command and a create topic command consecutively, even if it
> wait for the response of the previous command before issuing the second,
> there is still a race condition that the create topic command could be "lost".
> This is because currently these commands are all asynchronous as defined in
> KIP-4, and controller will return the response once it has written the
> corresponding data to ZK path, which can be handled by different listener
> threads at different paces, and if the thread handling create is faster than
> the other, the executions could be effectively re-ordered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
