cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Schuller <peter.schul...@infidyne.com>
Subject Re: Question on Eventual Consistency
Date Mon, 19 Jul 2010 19:43:22 GMT
> 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

Mime
View raw message