> Does anyone have any intuition about whether this will happen with
> consistency_level=ALL? I will try it today, but I'd like to know what the
> expected behavior is. It seems like it would not happen in this case.
Assuming my understanding is correct (see my comment in the JIRA
ticket), then
That's what I thought was happening, yes. A careful reading of the
documentation suggests that this is correct behavior.
Tyler says this can also occur because of a TimedOutException on the writes.
This worries me because TimedOutExceptions are so frequent (at least for my
test cluster), ther
James: I feel like I understand what's going on in your code now based on
this discussion, and I'm ok with the fact that DURING a QW you can get
"transitional" results from a QR in another process (or either the before or
after state of the QW). But once the QW succeeds, you must get the new
value
Same process or not: only successful QR reads after successful QW will
behave with this guarantee.
/***
sent from my android...please pardon occasional typos as I respond @ the
speed of thought
/
On Apr 17, 2011 10:04 AM, "James Cipar" wrote:
> For a
> For a second, I thought this thread was saying I could see value(s) < new
> value(s) within the same process on the second read at quorum
That's exactly what I'm saying. Within a single process I see this behavior,
when reading with consistency_level=QUORUM
Read value 1
Read value 2
Read val
Cool, that is exactly what I was thinking/expecting, and I feel better about
the assumptions I've used in my refactor to move from MySQL -> cassandra.
I basically gave up on trying to force my code to assume (even at quorum):
-read value(s) for key from cassandra
-update/add/delete columns for key
William
The issue is regarding whether you will see A or B; with any guarantee of
either. The discussion implies no; until the QW is complete.
/***
sent from my android...please pardon occasional typos as I respond @ the
speed of thought
/
On Apr 17, 20
Successful reads after a successful write @Q have the property of once the
read is seen @ one Q, the same read will be seen at any other Q.
All others are details that will change with implementation; but,imo, are
not bugs.
James: in your case, I would think that you have not completed a successf
I'm pretty new to all of this, and I'm in the process of building my mental
model of Cassandra, but I'm still feeling better about this thread. The way
I figure it:
1. I'm trying to mutate the state of a key's column from A to B from a
thread somewhere (quorum)
2. I'm trying to read the state of a
The bug report suggests a test with write_consistency=ONE,
read_consistency=QUORUM. If one thread is writing at consistency level ONE,
and the other is reading at QUORUM, I wouldn't expect consistent reads. The
problem I was talking about is when both reads and writes are using QUORUM.
Also,
On Sun, Apr 17, 2011 at 6:42 AM, William Oberman
wrote:
> At first I was concerned and was going to +1 on a fix, but I think I was
> confused on one detail and I'd like to confirm it.
> -An unsuccessful write implies readers can see either the old or new value
Yes. Fixing CASSANDRA-2494 will si
Thanks Jonathan, I've filed a bug for this,
https://issues.apache.org/jira/browse/CASSANDRA-2494
Sean
On Sat, Apr 16, 2011 at 10:53 PM, Jonathan Ellis wrote:
> Tyler is correct, because Cassandra doesn't wait until repair writes
> are acked before the answer is returned. This is something we ca
I'm pretty new to Cassandra, but I've also written a client in C++ using the
thrift API directly. From what I've seen, wrapping writes in a retry loop is
pretty much mandatory because if you are pushing a lot of data around, you're
basically guaranteed to have TimedOutExceptions. I suppose wha
At first I was concerned and was going to +1 on a fix, but I think I was
confused on one detail and I'd like to confirm it.
-An unsuccessful write implies readers can see either the old or new value
?
The trick is using a library, it sounds like there is a period of time a
write is unsuccessful b
Tyler is correct, because Cassandra doesn't wait until repair writes
are acked before the answer is returned. This is something we can fix.
On Sun, Apr 17, 2011 at 12:05 AM, Sean Bridges wrote:
> Tyler, your answer seems to contradict this email by Jonathan Ellis
> [1]. In it Jonathan says,
>
>
Tyler, your answer seems to contradict this email by Jonathan Ellis
[1]. In it Jonathan says,
"The important guarantee this gives you is that once one quorum read
sees the new value, all others will too. You can't see the newest
version, then see an older version on a subsequent write [sic, I
a
Here's what's probably happening:
I'm assuming RF=3 and QUORUM writes/reads here. I'll call the replicas A,
B, and C.
1. Writer process writes sequence number 1 and everything works fine. A,
B, and C all have sequence number 1.
2. Writer process writes sequence number 2. Replica A writes suc
Here it is. There is some setup code and global variable definitions that I
left out of the previous code, but they are pretty similar to the setup code
here.
import pycassa
import random
import time
consistency_level = pycassa.cassandra.ttypes.ConsistencyLevel.QUORUM
durat
James,
Would you mind sharing your reader process code as well?
On Fri, Apr 15, 2011 at 1:14 PM, James Cipar wrote:
> I've been experimenting with the consistency model of Cassandra, and I
> found something that seems a bit unexpected. In my experiment, I have 2
> processes, a reader and a wri
If you are reading and writing at quorum, then what you are seeing
shouldn't happen. You shouldn't be able to read N+1 until N+1 has
been committed to a quorum of servers. At this point you should not
be able to read N anymore, since there is no quorum that contains N.
Dan - I think you are righ
So Cassandra does not use an atomic commit protocol at the cluster level.
Strong consistency on a quorum read is only guaranteed *after* a successful
quorum write. The behaviour you are seeing is possible if you are reading in
the middle of a write or the write failed (which should be reported to y
21 matches
Mail list logo
