cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ran Tavory <>
Subject Re: Question on Eventual Consistency
Date Mon, 19 Jul 2010 19:48:28 GMT
On Mon, Jul 19, 2010 at 10:43 PM, Peter Schuller <> 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?

> 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

> > 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:
> You may also be interested in the Dynamo paper for background:
> 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

View raw message