One solution is to only read up to (now - 1 second). If this is a public
API where you want to guarantee full consistency (ie, if you have added a
message to the queue, it will definitely appear to be there) you can
instead delay requests for 1 second before reading up to the moment that
the reques
The "issue" is that it is possible for a quorum write to return an
error, but for the result of the write to still be reflected in the
view seen by the client. There is really no performant way around this
(although reading at ALL can make it much less frequent). Guaranteeing
complete success or fa
On Fri, Aug 17, 2012 at 8:00 AM, Nick Bailey wrote:
> This is actually incorrect. If you get an UnavailableException, the
> write was rejected by the coordinator and was not written anywhere.
Last time I checked, this was not true for batch writes. The row
mutations were started sequentially (ie,
Your update doesn't go directly to an sstable (which are immutable),
it is first merged to an in-memory table. Eventually the memtable is
flushed to a new sstable.
See http://wiki.apache.org/cassandra/MemtableSSTable
On Sat, Aug 11, 2012 at 11:03 AM, Aaron Turner wrote:
> So how does that work?
