[
https://issues.apache.org/jira/browse/KAFKA-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160772#comment-14160772
]
Neha Narkhede commented on KAFKA-1367:
--------------------------------------
The ISR cache on the broker was added only because we had to expose that
information through the topic metadata response. I don't think we gave a lot of
thought, back then, on why the ISR information is useful in the topic metadata
response (especially since it's stale and effectively inaccurate). I am not
entirely sure if having the controller be aware of all ISR changes is terrible
even though it's true that the # of watches it has to add is proportional to
the # of partitions in a cluster. But it's not worth doing that if we don't
find a use for the ISR information in the topic metadata response. So I'd vote
for removing ISR from topic metadata and also from the broker's metadata cache.
> 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
> Labels: newbie++
> 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)
