[
https://issues.apache.org/jira/browse/KAFKA-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neha Narkhede updated KAFKA-831:
--------------------------------
Attachment: kafka-831-v2.patch
Ack, you're right. The optimization of sending the leader and isr request only
if the leader is alive is flawed. This is because even if the leader is alive
at the time of the check, it can immediately go offline by the time the broker
is ready to act on the request. In any case, the replica manager does the
appropriate check just before executing the leader/follower state change on its
end.
- This patch removes the above optimization and sends the leader and isr
request for all partitions in Offline/Online state
- Note that, in the first request, the partitions in NewPartition state are not
included since they never had a leader. This is ok since it means that the
broker never started a log for such partitions. So there is no worry of
previously written checkpoint getting lost
> Controller does not send the complete list of partitions to a newly started
> broker
> ----------------------------------------------------------------------------------
>
> Key: KAFKA-831
> URL: https://issues.apache.org/jira/browse/KAFKA-831
> Project: Kafka
> Issue Type: Bug
> Components: controller
> Affects Versions: 0.8
> Reporter: Neha Narkhede
> Assignee: Neha Narkhede
> Priority: Blocker
> Labels: kafka-0.8, p1
> Attachments: kafka-831-v1.patch, kafka-831-v2.patch
>
>
> On a new broker startup, the controller is supposed to send the entire list
> of partitions that the new broker is supposed to host in one leader and isr
> request. In this request, it specifies if the new broker is the leader or
> follower for each of those partitions. For most of the partitions, the new
> broker will be a follower. However, for some partitions that don't have any
> other broker alive, the new broker will be the leader. The bug is that the
> controller first elects the leaders for offline partitons to see if the new
> broker is the leader for any of those and sends only those partitions for
> which leader was elected in the first leader and isr request. Right after
> that, it does send a leader and isr request with all partitions, but that
> breaks the guarantee that the very first leader and isr request has all
> partitions. As a result of this bug, the high watermark checkpointing logic
> behaves incorrectly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
