On Mon, Jul 19, 2010 at 10:43 PM, Peter Schuller < peter.schul...@infidyne.com> wrote:
> > 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? > no > > 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. > sorry... there could be other bugs, but queues and asyncs aren't involved... > > > 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 >
