I hadn't been following the discussions regarding 0.8 and replication for a little while and this was a great post to refresh my memory and get up to speed on the current replication architecture's design.
Felix On Tue, Feb 5, 2013 at 2:21 PM, Jun Rao <[EMAIL PROTECTED]> wrote:
Same here, summary was need as we have a fairly large ecosystem of multiple 0.7.2 clusters and I am planning to test upgrade to 0.8. However, one thing creeping at the back of my mind regarding 0.8 is something i have spotted in one thread few weeks ago namely that the rebalance behaviour of producers is not as robust as in 0.7.x without replication and i remeber there was no designed solution at the time - any news here ? Basically our usecase doesn't require replication but logical offsets and some other things introduced would solve some problems. On Feb 7, 2013 7:11 PM, "Vaibhav Puranik" <[EMAIL PROTECTED]> wrote:
So if the produces are partitioning by key we have to have replication if we dont want messages to get lost when partition goes down l right ? Thanks On Feb 8, 2013 5:12 AM, "Jun Rao" <[EMAIL PROTECTED]> wrote:
That's right. If you are partitioning by key, that means you insist a message has to go to a certain partition, whether it's available or not. So, if a partition is not available, we will drop the message for the partition in the async mode and consistently throw an exception to the caller in the sync mode.
On Fri, Feb 8, 2013 at 1:41 AM, Michal Haris <[EMAIL PROTECTED]>wrote:
Thanks Jun, makes sense. On Feb 8, 2013 4:00 PM, "Jun Rao" <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation projects and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext