Return-Path: 
 <user-return-29642-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org>
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 A64FBDD76
	for <apmail-cassandra-user-archive@www.apache.org>;
 Fri, 19 Oct 2012 16:51:25 +0000 (UTC)
Received: (qmail 18368 invoked by uid 500); 19 Oct 2012 16:51:23 -0000
Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org
Received: (qmail 18108 invoked by uid 500); 19 Oct 2012 16:51:21 -0000
Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@cassandra.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@cassandra.apache.org>
List-Post: <mailto:user@cassandra.apache.org>
List-Id: <user.cassandra.apache.org>
Reply-To: user@cassandra.apache.org
Delivered-To: mailing list user@cassandra.apache.org
Received: (qmail 18081 invoked by uid 99); 19 Oct 2012 16:51:21 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Oct 2012 16:51:20 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of edlinuxguru@gmail.com
 designates 209.85.223.172 as permitted sender)
Received: from [209.85.223.172] (HELO mail-ie0-f172.google.com)
 (209.85.223.172)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Oct 2012 16:51:15 +0000
Received: by mail-ie0-f172.google.com with SMTP id 9so1157775iec.31
        for <user@cassandra.apache.org>; Fri, 19 Oct 2012 09:50:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=3rNVb1IaOelDkMAkc8UKJBjjJ8s2i3GHHLv8srdYnNg=;
        b=VypheF8Y5R9ZuPtNF+ejMHQCflut2LXl+9D1pJx9bfiWVeFOtrTXCiWq14VbNtjB7N
         zDyxKTmzwObPV9zX99DMeRojOzKNH/53WHYOLDaYxAB5/ViJ7I1LYAtQ5wPqe33tj3MD
         7KQN+JGc/uTKz2GfqOkuhQlpDml7Q7pNUVa57g9DaVocwynsuXmPR19klbhgyLcFahM1
         t4BtN++gTo7VzozeDVcyaVvYOO2ARartT5THzEQOQXDf/jUOEBC5ZXlYLM+AInfwTfRo
         rTJQ/tU9QjJnfs8rkviV07rryBR3NYBBBzuGjbFlRNFQIRItJ69GBUAYScNHiHdS22ra
         wN9w==
MIME-Version: 1.0
Received: by 10.50.219.230 with SMTP id pr6mr2109580igc.29.1350665455367; Fri,
 19 Oct 2012 09:50:55 -0700 (PDT)
Received: by 10.64.97.106 with HTTP; Fri, 19 Oct 2012 09:50:55 -0700 (PDT)
In-Reply-To: 
 <CADJL=w5Typr8N5fe=7v4W-SeujM85uuWVKV91oMtND+SwXn-WA@mail.gmail.com>
References: 
 <CADJL=w5Typr8N5fe=7v4W-SeujM85uuWVKV91oMtND+SwXn-WA@mail.gmail.com>
Date: Fri, 19 Oct 2012 12:50:55 -0400
Message-ID: 
 <CAENxBwzFAOH3RcYEH2bWFH-sA6n+yJCWZDePaqeQ16ykpqabjQ@mail.gmail.com>
Subject: Re: unexpected behaviour on seed nodes when using
 -Dcassandra.replace_token
From: Edward Capriolo <edlinuxguru@gmail.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Checked: Checked by ClamAV on apache.org

Yes. That would be a good jira if it is not already listed. If node is
a seed node autobootstrap and replicate_token settings should trigger
a fatal non-start because your giving c* conflicting directions.

Edward

On Fri, Oct 19, 2012 at 8:49 AM, Thomas van Neerijnen
<tom@bossastudios.com> wrote:
> Hi all
>
> I recently tried to replace a dead node using
> -Dcassandra.replace_token=<token>, which so far has been good to me.
> However on one of my nodes this option was ignored and the node simply
> picked a different token to live at and started up there.
>
> It was a foolish mistake on my part because it was set as a seed node, which
> results in this error in the log file:
> INFO [main] 2012-10-19 12:41:00,886 StorageService.java (line 518) This node
> will not auto bootstrap because it is configured to be
>  a seed node.
> but it seems a little scary that this would mean it'll just ignore the fact
> that you want a replace a token and put itself somewhere else in the
> cluster. Surely it should behave similarly to trying to replace a live node
> by throwing some kind of exception?