[
https://issues.apache.org/jira/browse/KAFKA-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14563935#comment-14563935
]
Jun Rao commented on KAFKA-1367:
--------------------------------
There is actually a reasonable use case of ISR in KAFKA-2225. Basically, for
economical reasons, we may want to let a consumer fetch from a replica in ISR
that's in the same zone. In order to support that, it will be convenient to
have TMR return the correct ISR for the consumer to choose.
Implementation wise, one way to address the concern with too many watchers is
to do sth similar to changing topic configs. Basically, when the leader changes
the isr, in addition to writing the new isr in the partition state in ZK, it
also writes the change as a sequential node under a new isrChangeNotification
path in ZK. The controller listens to child changes in the
isrChangeNotification path. On child change, the controller reads the new isr
and broadcasts it through an UpdateMetadataRequest to every broker.
> 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)
