Prakash, you are configure the topic with a replication factor of only 1, i.e. no additional replica beyond "the original one". This replication setting of 1 means that only one of the two brokers will ever host the (single) replica -- which is implied to also be the leader in-sync replica -- of a given partition.
In step 3 you are disabling one of the two brokers. Because this stopped broker is the only broker that hosts one or more of the 3 partitions you configured (I can't tell which partition(s) it is, but you can find out by --describe'ing the topic), your Kafka cluster -- which is now running in degraded state -- will miss the leader of those affected partitions. And because you set the replication factor to 1, the remaining, second broker will not and will never take over the leadership of those partitions from the stopped broker. Hence you will keep getting the LeaderNotAvailableException's until you restart the stopped broker in step 7. So to me it looks as if the behavior of Kafka is actually correct and as expected. If you want to "rectify" your test setup, try increasing the replication factor from 1 to 2. If you do, you should be able to go through steps 1-8 without seeing LeaderNotAvailableExceptions (you may need to give Kafka some time to re-elect the remaining, second broker as the new leader for the first broker's partitions though). Hope this helps, Michael On 06/11/2014 07:49 PM, Prakash Gowri Shankor wrote: > yes, > here are the steps: > > Create topic as : ./kafka-topics.sh --topic test2 --create --partitions 3 > --zookeeper localhost:2181 --replication-factor 1 > > 1) Start cluster with 2 brokers, 3 consumers. > 2) Dont start any producer > 3) Shutdown cluster and disable one broker from starting > 4) restart cluster with 1 broker, 3 consumers > 5) Start producer and send messages. I see this exception > 6) Shutdown cluster. > 7) Enable 2nd broker. > 8) Restart cluster with 2 brokers, 3 consumer and the one producer and send > messages. Now I dont see the exception.
