Many thanks. Yes, it looks like a bug in 1.2.2. So far (6 runs)
v 1.2.9 is acting as I had expected.
(BTW re schema, I'm not defining anything myself so it is just the
default/empty schema for which I was getting disagreeing
Can I confirm I'm following best practice: when starting my
cluster, I pick 2 nodes as seed nodes, then set up and start all
the nodes in parallel, all configured to use those 2 seed nodes.
Is there any care recommended in the start-up order?
The docs suggest it doesn't matter too much so long as there is
enough information to discover all the nodes, but I've seen some
surprising behaviour. Besides the buggy 1.2.2, even with 1.2.9 if
you try to be smart and set seeds@node1=node2 and
seeds@node2=node1 it blows up rather spectacularly --  !
 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
On 09/09/2013 17:51, Robert Coli wrote: