were not immediately picked up 
They should be re-read on startup. 

if they were not let us know. 

Cheers

-----------------
Aaron Morton
Freelance Developer
@aaronmorton

On 29/02/2012, at 10:27 PM, Richard Evans wrote:

Spot on Aaron!

Of course when I set up the ring the aws nodes could see one another's internal addresses so I could let the broadcast address default.
I've now used external addresses for all broadcast (and seed) addresses and it all works fine.

[[ As a matter of interest, the adjusted values in cassandra.yaml were not immediately picked up so I zapped the data, which was not a problem in my case. I assume the conf values are stored in the system schema somewhere and that this kind of thing could be adjusted more subtly in a real-world situation. I'll study on but I'm very much liking what I've seen so far!]]

Thanks for your help,
Richard


From: aaron morton <aaron@thelastpickle.com>
Reply-To: <user@cassandra.apache.org>
Date: Wed, 29 Feb 2012 09:08:16 +1300
To: <user@cassandra.apache.org>
Subject: Re: Failed to join ring (NAT)

What is the broadcast address on the nodes inside aws ? 

Cheers
-----------------
Aaron Morton
Freelance Developer
@aaronmorton

On 29/02/2012, at 1:41 AM, Richard Evans wrote:

I have a small ring of two nodes running successfully on aws. 

In order to understand cassandra support for NAT I have tried to add another node outside aws on a machine behind NAT.
When I try to join the ring, there is a 30s pause after starting the messaging service and  then it fails, unable to find other nodes.

 12:16:29,834 Starting Messaging Service on port 7000
 INFO 12:16:29,848 JOINING: waiting for ring and schema information
 INFO 12:16:59,849 JOINING: schema complete, ready to bootstrap
 INFO 12:16:59,850 JOINING: getting bootstrap token
ERROR 12:16:59,853 Exception encountered during startup
java.lang.RuntimeException: No other nodes seen!  Unable to bootstrap.If you intended to start a single-node cluster, you should make sure your broadcast_address (or listen_address) is listed as a seed.  Otherwise, you need to determine why the seed being contacted has no knowledge of the rest of the cluster.  Usually, this can be solved by giving all nodes the same seed list.
at org.apache.cassandra.dht.BootStrapper.getBootstrapSource(BootStrapper.java:168)
at org.apache.cassandra.dht.BootStrapper.getBalancedToken(BootStrapper.java:150)

The new node config 
seed_provider:
 - seeds: <awsNode1 external address>

listen_address: <newNode internal address> 
broadcast_address: <newNode external address>

The AWS security group config..
Admits traffic from <newNode external address> on ports 7000, 7001, 8080

Netwok paths
When the new node was attempting to start, I proved the paths between the seed and the new node. I could .
 - telnet from awsNode1 to newNode 7000
 - telnet from newNode to awsNode1 7000

Can anyone spot my beginner's mistake? 
Thanks,
Richard