I think you're conflating "may" with "must".  That article says that updates "may" still be applied to some replicas when there is a failure and I believe that still is the case.  However, if the coordinator knows that the CL can't be met before even attempting the write, I don't think it will attempt the write.

-Bryan



On Fri, May 17, 2013 at 1:48 AM, Sergey Naumov <sknaumov@gmail.com> wrote:
As described here (http://maxgrinev.com/2010/07/12/update-idempotency-why-it-is-important-in-cassandra-applications-2/), if consistency level couldn't be met, updates are applied anyway on functional replicas, and they could be propagated later to other replicas using repair mechanisms or by issuing the same request later, as update operations are idempotent in Cassandra.

But... on my configuration (Cassandra 1.2.4, python CQL 1.0.4, DC1 - 3 nodes, DC2 - 3 nodes, DC3 - 1 node, RF={DC1:3, DC2:2, DC3:1}, Random Partitioner, GossipingPropertyFileSnitch, one node in DC1 is deliberately down - and, as RF for DC1 is 3, this down node is a replica node for 100% of records),  when I try to insert one record with consistency level of ALL, this insert does not appear on any replica (-s30 - is a serial of UUID1: 0000001e-0000-1000-0000-xxxxxxxxxxxxx (30 is 1e in hex), -n1 mean that we will insert/update a single record with first id from this series - 0000001e-0000-1000-0000-000000000000):
write with consistency ALL:
cassandra@host11:~/Cassandra$ ./insert.sh -s30 -n1 -cALL
Traceback (most recent call last):
  File "./aux/fastinsert.py", line 54, in insert
    curs.execute(cmd, consistency_level=p.conlvl)
OperationalError: Unable to complete request: one or more nodes were unavailable.
Last record UUID is 0000001e-0000-1000-0000-000000000000

about 10 seconds passed...

read with consistency ONE:

cassandra@host11:~/Cassandra$ ./select.sh -s30 -n1 -cONE
Total records read: 0
Last record UUID is 0000001e-0000-1000-0000-000000000000
read with consistency QUORUM:
cassandra@host11:~/Cassandra$ ./select.sh -s30 -n1 -cQUORUM
Total records read: 0
Last record UUID is 0000001e-0000-1000-0000-000000000000
write with consistency QUORUM:
cassandra@host11:~/Cassandra$ ./insert.sh -s30 -n1 -cQUORUM
Last record UUID is 0000001e-0000-1000-0000-000000000000
read with consistency QUORUM:
cassandra@host11:~/Cassandra$ ./select.sh -s30 -n1 -cQUORUM
Total records read: 1
Last record UUID is 0000001e-0000-1000-0000-000000000000

Is it a new feature of Cassandra that it does not perform a write to any replica if consistency couldn't be satisfied? If so, then is it true for all cases, for example when returned error is "OperationalError: Request did not complete within rpc_timeout"?

Thanks in advance,
Sergey Naumov.