> I'm using CL=QUORUM (=Hector default) for both reads and writes. Most of the > times, the test passes, but sometimes it fails because I get back the old > value. Since the test is single-threaded, I guess it is a bug. I'll try to > reduce the test to something smaller that can be used for troubleshooting.
I have never used or looked at the source of Hector; but is it at all possible that Hector is making the write asynchronous by putting it on a queue of some kind, serviced by a pool of workers? To be clear, this is *pure* speculation and may be completely out of the question. It's an attempt to think up an hypothesis other than a Cassandra bug to explain what you're seeing. > By the way, is it documented somewhere under what circumstances one can > expect inconsistencies and when not? Not sure if consistency is dealt with in more depth somewhere, but one point talking about consistency levels is: http://wiki.apache.org/cassandra/API You may also be interested in the Dynamo paper for background: http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html Unless I have seriously misunderstood something, you're definitely expected to get the consistency you are after with QUOROM - under the assumption that you use QUOROM for both reads and writes of the data in question, as you say you do. If you further need durability (so that you don't lose said consistency in the event of cassandra nodes going done in an uncontrolled fashion), you'll want to turn on batch wise commits rather than periodic commits in Cassandra. Expect that to imply a potentially significant performance penalty though, depending primarily on what your commit log is stored on. -- / Peter Schuller
