Re: count after truncate NOT zero

2012-05-08 Thread aaron morton
Some 'feature' for future implementation, maybe? imho truncation working as a meta data operation is the correct approach. It's generally used in testing and development. It deletes the data and removes the SSTables, giving you a clean state. A CF level tombstone would mean that reads had to

Re: count after truncate NOT zero

2012-05-07 Thread aaron morton
I don't know the YCSB code, but one theory would be… 1) The cluster is overloaded by the test. 2) A write at CL ALL fails because a node does not respond in time. 3) The coordinator stores the hint and returns failure to the client. 4) The client gets an UnavailableException and retries the

count after truncate NOT zero

2012-05-03 Thread Peter Dijkshoorn
Hi guys, I got a weird thingy popping up twice today, I run a test where I insert a milion records via YCSB and edited it to allow me to adjust the consistency level: the write operations are done with ConsistencyLevel.ALL. This is send to a 4 (virtual) node cluster with a keyspace 'test' set up