It's not being switched in this case because the broker hasn't failed. It can still connect to all the other brokers and zookeeper. The only failure is of the link between a client and the broker.
Another way to think of this is to extend the scenario with more producers. If I have 100 other producers and they can all still connect, would you still consider this a failure and expect the leader to change? Since network partitions (or periods of high latency, or long GC pauses, etc) can happen arbitrarily and clients might be spread far and wide, you can't rely on their connectivity as an indicator of the health of the Kafka broker. Of course, there's also a pretty big practical issue: since the client can't connect to the broker, how would it even report that it has a connectivity issue? -Ewen On Mon, May 25, 2015 at 10:05 PM, Kamal C <kamaltar...@gmail.com> wrote: > Hi, > > I have a cluster of 3 Kafka brokers and a remote producer. Producer > started to send messages to *SampleTopic*. Then I blocked the network > connectivity between the Producer and the leader node for the topic > *SampleTopic* but network connectivity is healthy between the cluster and > producer is able to reach the other two nodes. > > *With Script* > > sh kafka-topics.sh --zookeeper localhost --describe > Topic:SampleTopic PartitionCount:1 ReplicationFactor:3 Configs: > Topic: SampleTopic Partition: 0 Leader: 1 Replicas: 1,2,0 > Isr: 1,2,0 > > > Producer tries forever to reach the leader node by throwing connection > refused exception. I understand that when there is a node failure leader > gets switched. Why it's not switching the leader in this scenario ? > > -- > Kamal C > -- Thanks, Ewen