From user-return-17742-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Wed Jun 15 19:28:57 2011 Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 324854738 for ; Wed, 15 Jun 2011 19:28:57 +0000 (UTC) Received: (qmail 1732 invoked by uid 500); 15 Jun 2011 19:28:54 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 1693 invoked by uid 500); 15 Jun 2011 19:28:54 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 1685 invoked by uid 99); 15 Jun 2011 19:28:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Jun 2011 19:28:54 +0000 X-ASF-Spam-Status: No, hits=2.9 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [204.13.248.74] (HELO mho-02-ewr.mailhop.org) (204.13.248.74) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Jun 2011 19:28:47 +0000 Received: from 67-6-236-30.hlrn.qwest.net ([67.6.236.30] helo=[192.168.0.2]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1QWvlI-000Cpj-HT for user@cassandra.apache.org; Wed, 15 Jun 2011 19:28:25 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.6.236.30 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18rv7LbBPFU8bQ8DoZus4Lp6VVGGIzZhGc= Message-ID: <4DF907CF.2060302@dude.podzone.net> Date: Wed, 15 Jun 2011 13:28:15 -0600 From: AJ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: user@cassandra.apache.org Subject: Re: Docs: Token Selection References: <4DF7E4E5.90709@dude.podzone.net> <4DF8197F.1040501@dude.podzone.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080704050000080605060308" This is a multi-part message in MIME format. --------------080704050000080605060308 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/15/2011 12:14 PM, Vijay wrote: > Correction.... > > "The problem in the above approach is you have 2 nodes between 12 to 4 > in DC1 but from 4 to 12 you just have 1" > > should be > > "The problem in the above approach is you have 1 node between 0-4 > (25%) and and one node covering the rest which is 4-16, 0-0 (75%)" > > Regards, > > Ok, I think you are saying that the computed token range intervals are incorrect and that they would be: DC1 *node 1 = 0 Range: (4, 16], (0, 0] node 2 = 4 Range: (0, 4] DC2 *node 3 = 8 Range: (12, 16], (0, 8] node 4 = 12 Range: (8, 12] If so, then yes, this is what I am seeking to confirm since I haven't found any documentation stating this directly and that reference that I gave only implies this; that is, that the token ranges are calculated per data center rather than per cluster. I just need someone to confirm that 100% because it doesn't sound right to me based on everything else I've read. SO, the question is: Does Cass calculate the consecutive node token ranges A.) per cluster, or B.) for the whole data center? From all I understand, the answer is B. But, that documentation (reprinted below) implies A... or something that doesn't make sense to me because of the token placement in the example: "With NetworkTopologyStrategy, you should calculate the tokens the nodes in each DC independantly... DC1 node 1 = 0 node 2 = 85070591730234615865843651857942052864 DC2 node 3 = 1 node 4 = 85070591730234615865843651857942052865" However, I do see why this would be helpful, but first I'm just asking if this token assignment is absolutely mandatory or if it's just a technique to achieve some end. --------------080704050000080605060308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 6/15/2011 12:14 PM, Vijay wrote:
Correction.... 

"The problem in the above approach is you have 2 nodes between 12 to 4 in DC1 but from 4 to 12  you just have 1"

should be

"The problem in the above approach is you have 1 node between 0-4 (25%) and and one node covering the rest which is 4-16, 0-0 (75%)"

Regards,
</VJ>


Ok, I think you are saying that the computed token range intervals are incorrect and that they would be:

DC1
*node 1 = 0      Range: (4, 16], (0, 0]
node 2 = 4      Range: (0, 4]

DC2
*node 3 = 8      Range: (12, 16], (0, 8]
node 4 = 12   Range: (8, 12]

If so, then yes, this is what I am seeking to confirm since I haven't found any documentation stating this directly and that reference that I gave only implies this; that is, that the token ranges are calculated per data center rather than per cluster.  I just need someone to confirm that 100% because it doesn't sound right to me based on everything else I've read. 

SO, the question is:  Does Cass calculate the consecutive node token ranges A.) per cluster, or B.) for the whole data center?

From all I understand, the answer is B.  But, that documentation (reprinted below) implies A... or something that doesn't make sense to me because of the token placement in the example:

"With NetworkTopologyStrategy, you should calculate the tokens the nodes in each DC independantly...

DC1
node 1 = 0
node 2 = 85070591730234615865843651857942052864

DC2
node 3 = 1
node 4 = 85070591730234615865843651857942052865"


However, I do see why this would be helpful, but first I'm just asking if this token assignment is absolutely mandatory 
or if it's just a technique to achieve some end.


--------------080704050000080605060308--