[
https://issues.apache.org/jira/browse/KAFKA-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143218#comment-14143218
]
Magnus Edenhill commented on KAFKA-1367:
----------------------------------------
Apart from supplying the ISR count and list in its metadata API, librdkafka
also provides an `enforce.isr.cnt` configuration property that fails
produce requests locally before transmission if the currently known ISR count
is smaller than the configured value.
This is a workaround for the broker not fully honoring `request.required.acks`,
i.e., if `request.required.acks=3` and only one broker is available the produce
request will not fail.
More info in the original issue here:
https://github.com/edenhill/librdkafka/issues/91
Generally I would assume that information provided by the broker is correct,
otherwise it should not be included at all since it can't be used (reliably).
> 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)
