[
https://issues.apache.org/jira/browse/KAFKA-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13752793#comment-13752793
]
Neha Narkhede commented on KAFKA-1030:
--------------------------------------
Longer term, the right fix will be to move rebalancing to the controller and
let it co-ordinate state changes for the consumer. Until then, it will be some
sort of a work around to get the latest state changes. To your point, if
controller failover is happening, the rebalance attempt will fail. This is no
different from leadership changes. I don't see why we need controller failover
watch. This controller metadata is only required when partitions change, so it
is on-demand.
> Addition of partitions requires bouncing all the consumers of that topic
> ------------------------------------------------------------------------
>
> Key: KAFKA-1030
> URL: https://issues.apache.org/jira/browse/KAFKA-1030
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Swapnil Ghike
> Assignee: Swapnil Ghike
> Priority: Blocker
> Fix For: 0.8
>
>
> Consumer may not notice new partitions because the propagation of the
> metadata to servers can be delayed.
> Options:
> 1. As Jun suggested on KAFKA-956, the easiest fix would be to read the new
> partition data from zookeeper instead of a kafka server.
> 2. Run a fetch metadata loop in consumer, and set auto.offset.reset to
> smallest once the consumer has started.
> 1 sounds easier to do. If 1 causes long delays in reading all partitions at
> the start of every rebalance, 2 may be worth considering.
>
--
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
