[
https://issues.apache.org/jira/browse/KAFKA-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564029#comment-14564029
]
Jun Rao commented on KAFKA-1367:
--------------------------------
Well, in that approach, you still have the problem on the very first fetch
request. If ISR is not returned in TMR, the first fetch request has to go to
the leader. Then the consumer has to switch to another broker on a subsequent
request, which seems more complicated.
I am not sure if we need to rely on periodic metadata refresh to detect whether
a replica is out of sync. Basically, as long as the fetch offset is less than
HW, the replica can serve the request. If the fetch offset is larger than HW
(an indication that the replica is out of sync), the consumer will get an
OffsetOutOfRangeException and has to refresh the metadata and pick a new broker
to fetch from.
> Broker topic metadata not kept in sync with ZooKeeper
> -----------------------------------------------------
>
> Key: KAFKA-1367
> URL: https://issues.apache.org/jira/browse/KAFKA-1367
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.8.0, 0.8.1
> Reporter: Ryan Berdeen
> Assignee: Ashish K Singh
> Labels: newbie++
> Fix For: 0.8.3
>
> Attachments: KAFKA-1367.txt
>
>
> When a broker is restarted, the topic metadata responses from the brokers
> will be incorrect (different from ZooKeeper) until a preferred replica leader
> election.
> In the metadata, it looks like leaders are correctly removed from the ISR
> when a broker disappears, but followers are not. Then, when a broker
> reappears, the ISR is never updated.
> I used a variation of the Vagrant setup created by Joe Stein to reproduce
> this with latest from the 0.8.1 branch:
> https://github.com/also/kafka/commit/dba36a503a5e22ea039df0f9852560b4fb1e067c
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
