Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka >> mail # dev >> [jira] [Updated] (KAFKA-1030) Addition of partitions requires bouncing all the consumers of that topic


Copy link to this message
-
[jira] [Updated] (KAFKA-1030) Addition of partitions requires bouncing all the consumers of that topic

     [ https://issues.apache.org/jira/browse/KAFKA-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Swapnil Ghike updated KAFKA-1030:
---------------------------------

    Description:
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.
 
The same issue affects MirrorMaker when new topics are created, MirrorMaker may not notice all partitions of the new topics until the next rebalance.

  was:
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.
 

    
> 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.
>  
> The same issue affects MirrorMaker when new topics are created, MirrorMaker may not notice all partitions of the new topics until the next rebalance.

--
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

 
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB