Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 29 Dec 2016 02:17:58 +0000 (UTC)
From: "Dikang Gu (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13030771.1482868628000.610773.1482977878806@Atlassian.JIRA>
In-Reply-To: <JIRA.13030771.1482868628000@Atlassian.JIRA>
References: <JIRA.13030771.1482868628000@Atlassian.JIRA> <JIRA.13030771.1482868628409@arcas>
Subject: [jira] [Comment Edited] (CASSANDRA-13080) Use new token allocation
 for non bootstrap case as well.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 29 Dec 2016 02:18:05 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-13080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15784275#comment-15784275 ] 

Dikang Gu edited comment on CASSANDRA-13080 at 12/29/16 2:16 AM:
-----------------------------------------------------------------

[~blambov], thanks for review!

1. I think we still need the {{RF=0}}, because even we join the new node without streaming data, we don't want to set the RF to be non-zero, until we have enough capacity to handle the writes.
2. We still need the {{waitForSchema}} in the {{StorageService.joinTokenRing}}, in the replacement case as well, right? Which will be outside of the {{allocateTokens}}
3. Yeah, I think we should be able to allocate tokens for seed node as well, which does not seem to need any changes inside the algorithm. Do you want to allocate tokens for the first RF node as well?
4. Sure I will create a separate ticket to add the dtests.

Do they make sense?


was (Author: dikanggu):
[~blambov], thanks for review!

1. I think we still need the {{RF=0}}, because even we join the new node without streaming data, we don't want to set the RF to be non-zero, until we have enough capacity to handle the writes.
2. We still need the {{waitForSchema}} in the {{StorageService.joinTokenRing}}, in the replacement case as well, right? Which will be outside of the {{allocateTokens}}
3. Yeah, I think we should be able to allocate tokens for seed node as well, which does not seem to need any changes inside the algorithm. Do you want to allocate tokens for the first RF node as well?
4. Sure I will create a separate to add the dtests.

Do they make sense?

> Use new token allocation for non bootstrap case as well.
> --------------------------------------------------------
>
>                 Key: CASSANDRA-13080
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13080
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Dikang Gu
>            Assignee: Dikang Gu
>             Fix For: 3.12
>
>
> There are couple reasons I think we should use the new token allocation for non bootstrap case as well.
> 1. In some cases, We want to bring up nodes, but do not need to stream any data to the new nodes. So we want to allocate correct tokens, and skip the JOIN state, which should avoid triggering pending range calculation on other nodes as well. On use case is when we bring up a new DC.
> 2. We can unify the token allocation code path for both bootstrap and non-bootstrap use case.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)