This is incorrect. IMO that page is misleading.
replicate on write should normally always be turned on, or the change
will only be recorded on one node. Replicate on write is asynchronous
with respect to the request and doesn't affect consistency level at
all.
On Wed, May 29, 2013 at 7:32 PM, An
I agree, the page is clearly misleading in its formulation.
However, for the sake of being precise, I'll note that it is not untrue
strictly speaking.
If replicate_on_write is true (the default that you should probably not
change unless you consider yourself an expert in the Cassandra counters
imp
Ok, looking at the code I can see that 1.2 fixes the issue:
try
{
validBufferBytes =
metadata.compressor().uncompress(compressed.array(), 0, chunk.length,
buffer, 0);
}
catch (IOException e)
{
throw new CorruptBlockException(getPath(),
What was the node doing right before the ERROR? Can you post some more log?
Thanks,SC
Date: Fri, 31 May 2013 10:57:38 +0530
From: himanshu.jo...@orkash.com
To: user@cassandra.apache.org
Subject: java.lang.AssertionError on starting the node
Hi,
I have created a 2 nod
Hi Keith... Thanks for all your help so far.
I've done some additional testing and I can see no difference between
having all the columns as part of the primary key or having only a subset.
Granted, in my contrived example there is no benefit to having all the
columns in the primary key, but I be
Another option is not having it part of the primary key and using PlayOrm to
query but to succeed and scale, you would need to also use PlayOrm partitions
and then you can query in the partition and sort stuff.
Dean
From: Daniel Morton mailto:dan...@djmorton.com>>
Reply-To: "user@cassandra.apac
On Fri, May 31, 2013 at 7:44 AM, horschi wrote:
> But does nobody else find the old behaviour annoying? Nobody ever wanted to
> identfy the broken files?
I found it annoying, as did (presumably) whomever patched it for 1.2. :D
=Rob
