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, >...
