Return-Path: Delivered-To: apmail-incubator-cassandra-commits-archive@minotaur.apache.org Received: (qmail 30913 invoked from network); 26 Oct 2009 21:19:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 26 Oct 2009 21:19:24 -0000 Received: (qmail 86616 invoked by uid 500); 26 Oct 2009 21:19:24 -0000 Delivered-To: apmail-incubator-cassandra-commits-archive@incubator.apache.org Received: (qmail 86601 invoked by uid 500); 26 Oct 2009 21:19:23 -0000 Mailing-List: contact cassandra-commits-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-dev@incubator.apache.org Delivered-To: mailing list cassandra-commits@incubator.apache.org Received: (qmail 86591 invoked by uid 99); 26 Oct 2009 21:19:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Oct 2009 21:19:23 +0000 X-ASF-Spam-Status: No, hits=-10.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Oct 2009 21:19:20 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 3D406234C1F1 for ; Mon, 26 Oct 2009 14:19:00 -0700 (PDT) Message-ID: <663374956.1256591940249.JavaMail.jira@brutus> Date: Mon, 26 Oct 2009 21:19:00 +0000 (UTC) From: "Jonathan Ellis (JIRA)" To: cassandra-commits@incubator.apache.org Subject: [jira] Updated: (CASSANDRA-483) clean up bootstrap code, 2 In-Reply-To: <1858643261.1255041871276.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-483: ------------------------------------- Attachment: (was: 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt) > clean up bootstrap code, 2 > -------------------------- > > Key: CASSANDRA-483 > URL: https://issues.apache.org/jira/browse/CASSANDRA-483 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Reporter: Jonathan Ellis > Assignee: Jonathan Ellis > Fix For: 0.5 > > Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt > > > existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated. > in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code. > (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.