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 successful
@Q write; before attempting a read. The results are reflective of an
incomplete write (or, in other words, eventual consistency)

Sean: I don't see blocking for a read in the manner articulated is
appropriate,  IMO.

Regards
Milind

/***********************
sent from my android...please pardon occasional typos as I respond @ the
speed of thought
************************/

On Apr 17, 2011 7:47 AM, "James Cipar" <jci...@cmu.edu> wrote:

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, to make the tests more reliable, if you turn the replication factor
way up you will trigger more errors.  Also, if you have another process
producing background traffic to slow things down you will trigger more
errors.



On Apr 17, 2011, at 10:31 AM, Sean Bridges wrote:

> Thanks Jonathan, I've filed a bug for this,
>...

Reply via email to