The value of the state path for a partition in ZK can be updated by both
the controller (for choosing the new leader and potentially shrinking Isr)
and the leader replica (for expanding/shrinking Isr). After the controller
modified the state path, we don't want the old leader to modify Isr
anymore. So, the leader updates the state path in ZK conditionally and the
controller passes the latest ZK version of the path to the new leader in
the LeaderAnd Isr request (the leader will then refresh the expected ZK
version). In your case, it seems like that somehow broker 1 didn't receive
or process the latest LeaderAndIsr request. You can look at the controller
and the state-change log to see when the controller changed the leader for
that partition last time and whether the associated LeaderAndIsr request
was propagated to and processed at broker 1.


On Wed, Oct 16, 2013 at 4:52 AM, Sam Meder <[EMAIL PROTECTED]>wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB