[
https://issues.apache.org/jira/browse/KAFKA-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802546#comment-13802546
]
Joe Stein commented on KAFKA-1097:
----------------------------------
So, quick question. If you have 3 brokers with replication 3 then this issue
would not occur, right? If not then I am not understanding the problem :(
> Race condition while reassigning low throughput partition leads to incorrect
> ISR information in zookeeper
> ----------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-1097
> URL: https://issues.apache.org/jira/browse/KAFKA-1097
> Project: Kafka
> Issue Type: Bug
> Components: controller
> Affects Versions: 0.8
> Reporter: Neha Narkhede
> Assignee: Neha Narkhede
> Priority: Critical
> Fix For: 0.8
>
>
> While moving partitions, the controller moves the old replicas through the
> following state changes -
> ONLINE -> OFFLINE -> NON_EXISTENT
> During the offline state change, the controller removes the old replica and
> writes the updated ISR to zookeeper and notifies the leader. Note that it
> doesn't notify the old replicas to stop fetching from the leader (to be fixed
> in KAFKA-1032). During the non-existent state change, the controller does not
> write the updated ISR or replica list to zookeeper. Right after the
> non-existent state change, the controller writes the new replica list to
> zookeeper, but does not update the ISR. So an old replica can send a fetch
> request after the offline state change, essentially letting the leader add it
> back to the ISR. The problem is that if there is no new data coming in for
> the partition and the old replica is fully caught up, the leader cannot
> remove it from the ISR. That lets a non existent replica live in the ISR at
> least until new data comes in to the partition
--
This message was sent by Atlassian JIRA
(v6.1#6144)
