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

Emmett Butler commented on KAFKA-2154:
--------------------------------------

I've been able to replicate this issue on Debian 7.8 running Kafka 0.8.2.1. 
Currently I'm working around it by manually creating a topic whenever I spin up 
a fresh cluster. However, needing to do this in production is suboptimal.

> MetadataResponse is Empty on a Fresh Cluster
> --------------------------------------------
>
>                 Key: KAFKA-2154
>                 URL: https://issues.apache.org/jira/browse/KAFKA-2154
>             Project: Kafka
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 0.8.1.1
>            Reporter: Keith Bourgoin
>
> When I start a fresh cluster using {{bin/kafka-server-start.sh}} and issue a 
> MetadataRequest to it, the results are blank.  It's correct that there are no 
> topics, but there are also no brokers returned.  I'm writing a driver for 
> Kafka, so this makes the initial connection to the cluster difficult.
> To reproduce:
>   * Start Zookeeper with {{bin/zookeeper-server-start.sh 
> config/zookeeper.properties}} and a broker with {{bin/kafka-server-start.sh 
> config/server.properties}}.  Be sure there's nothing in {{/tmp}} from a 
> previous run.
>   * Run this {{echo -e 
> "\x00\x00\x00\x15\x00\x03\x00\x01\x00\x00\x00\x00\x00\x07pykafka\x00\x00\x00\x00"
>  | nc localhost 9092 | hd}} and observe the output:
>     {noformat}
> 00000000  00 00 00 0c 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 00000010
>     {noformat}
>   * Create a topic using {{bin/kafka-topics.sh --zookeeper localhost:2181 
> --create --topic test --partitions 2 --replication-factor 1}}
>   * Re-run the same command and now observe the output:
>     {noformat}
> kfb@parsely-dev:~/src/ct/pykafka$ echo -e 
> "\x00\x00\x00\x15\x00\x03\x00\x01\x00\x00\x00\x00\x00\x07pykafka\x00\x00\x00\x00"
>  | nc localhost 9092 | hd
> 00000000  00 00 00 61 00 00 00 00  00 00 00 01 00 00 00 00  |...a............|
> 00000010  00 0b 70 61 72 73 65 6c  79 2d 64 65 76 00 00 23  |..parsely-dev..#|
> 00000020  84 00 00 00 01 00 00 00  04 74 65 73 74 00 00 00  |.........test...|
> 00000030  02 00 00 00 00 00 01 00  00 00 00 00 00 00 01 00  |................|
> 00000040  00 00 00 00 00 00 01 00  00 00 00 00 00 00 00 00  |................|
> 00000050  00 00 00 00 00 00 00 00  01 00 00 00 00 00 00 00  |................|
> 00000060  01 00 00 00 00                                    |.....|
> 00000065
>     {noformat}
> In this case, "parsely-dev" is the name of my work VM and the "#" following 
> it is the port number.  I've verified it's a correctly formatted 
> MetadataResponse.  It's the first null result that we've having a hard time 
> dealing with.
> As for the bytestring, that's a correctly formatted MetadataRequest with no 
> topics specified.  Presumably if I specified a topic name it would 
> auto-create the topic and then start returning broker information.  It 
> doesn't really change the fact that the initial state is fairly broken.
> Finally, it's worth noting that if I delete the "test" topic (after turning 
> on {{delete.topic.enable}}) then the responses still include broker 
> information. It's just the initial state which is causing problems.
> {noformat}
> kfb@parsely-dev:~/src/kafka$ bin/kafka-topics.sh --zookeeper localhost:2181 
> --delete --topic test
> Topic test is marked for deletion.
> Note: This will have no impact if delete.topic.enable is not set to true.
> kfb@parsely-dev:~/src/ct/pykafka$ echo -e 
> "\x00\x00\x00\x15\x00\x03\x00\x01\x00\x00\x00\x00\x00\x07pykafka\x00\x00\x00\x00"
>  | nc localhost 9092 | hd
> 00000000  00 00 00 21 00 00 00 00  00 00 00 01 00 00 00 00  |...!............|
> 00000010  00 0b 70 61 72 73 65 6c  79 2d 64 65 76 00 00 23  |..parsely-dev..#|
> 00000020  84 00 00 00 00                                    |.....|
> 00000025
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to