[ https://issues.apache.org/jira/browse/KAFKA-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15102791#comment-15102791 ]
Mayuresh Gharat commented on KAFKA-3083: ---------------------------------------- [~junrao], [~fpj] that makes it more clear. I was just thinking if we can modify the controller code to always check if it is the controller before it makes such changes to zookeeper. Again there is a race condition, wherein Broker A's session timesOut at time T. Broker B becomes the controller at T+2. Broker A can still proceed with the changes to ZK between T and T+2. I had some questions on the zookeeper session expiry: 1) If suppose a broker establishes a connection with zookeeper and has a ZookeeperSessionTimeout set to 10 min.The broker goes down/or is stuck and comes back up and connects to zookeeper after 5 min, will it connect on the same session? 2) The session Expiry is only invoked on SessionTimeout and nothing else. Am I right? > a soft failure in controller may leader a topic partition in an inconsistent > state > ---------------------------------------------------------------------------------- > > Key: KAFKA-3083 > URL: https://issues.apache.org/jira/browse/KAFKA-3083 > Project: Kafka > Issue Type: Bug > Components: core > Affects Versions: 0.9.0.0 > Reporter: Jun Rao > Assignee: Mayuresh Gharat > > The following sequence can happen. > 1. Broker A is the controller and is in the middle of processing a broker > change event. As part of this process, let's say it's about to shrink the isr > of a partition. > 2. Then broker A's session expires and broker B takes over as the new > controller. Broker B sends the initial leaderAndIsr request to all brokers. > 3. Broker A continues by shrinking the isr of the partition in ZK and sends > the new leaderAndIsr request to the broker (say C) that leads the partition. > Broker C will reject this leaderAndIsr since the request comes from a > controller with an older epoch. Now we could be in a situation that Broker C > thinks the isr has all replicas, but the isr stored in ZK is different. -- This message was sent by Atlassian JIRA (v6.3.4#6332)