Could we revert / refactor this:
https://github.com/apache/cassandra/commit/c57e7c9e
Testing something in trunk and the above refactor prevents CL > ONE reads.
The exception is:
ERROR 19:51:52,271 Internal error processing get_counter
java.lang.AssertionError:
org.apache.cassandra.service.DigestM
or the test harness? (github is picking up the
> cassandra
> one)
>
> On Tue, Dec 14, 2010 at 7:45 PM, Kelvin Kakugawa
> wrote:
>
> > Hi devs,
> >
> > A number of us have been doing our own ad-hoc distributed testing. i.e.
> > manually putting up a cluster and the
Hi devs,
A number of us have been doing our own ad-hoc distributed testing. i.e.
manually putting up a cluster and then running a script to perform a series
of tests against it. [e.g., see: CASSANDRA-1072's increment_test.py]
However, this approach does not scale and we'd like to formalize a
di
Hi Simon,
Would you be able to use this git branch:
https://github.com/kakugawa/cassandra/tree/1502-to-1072
It's the most up-to-date version and you won't have to fool around w/
applying a patch. Since, to apply the patch, your repo has to be at
the same commit (in trunk) that I cut it from. (I
If anyone on the thread hasn't read Helland's Building on Quicksand
paper, yet, it discusses the abstract strategy behind #1072's
distributed counter implementation. It's here:
http://blogs.msdn.com/b/pathelland/archive/2008/12/12/building-on-quicksand-paper-for-cidr-conference-on-innovative-datab
Hi Robin,
Johan and I have brought the code up to trunk. It's ready to be
reviewed. However, in Jonathan's defense, it does require separate
code paths. Since, we're aggregating commutative operations, not
updating a value.
I think the underlying unanswered question is whether #1072 is a niche
