Hi, I'm also wondering if failed read/results phase (phase 2 in C* paxos) is recovered by some other reads or not. It seems easier to just return "failed" to clients if the phase 2 failed, because none of proposals are actually initiated. Does anyone know about it ?
Thanks, Hiroyuki On Wed, Jun 29, 2016 at 11:45 AM, Yuji Ito <y...@imagine-orb.com> wrote: > Tyler > > Thank you for your reply. > I have 2 questions. > > Will the reads resume the CAS operation? > > Do the reads repair in-progress paxos writes in read/results phase too? > According to the following article, > when an UnavailableException or a WriteTimeoutException occur (propose or > commit phase fail), > reads will force Cassandra to commit the data. > http://www.datastax.com/dev/blog/cassandra-error-handling-done-right > > Regards, > Yuji Ito > > > On Wed, Jun 29, 2016 at 7:03 AM, Tyler Hobbs <ty...@datastax.com> wrote: >> >> Reads at CL.SERIAL will complete any in-progress paxos writes, so the >> behavior you're seeing is expected. >> >> On Mon, Jun 27, 2016 at 1:55 AM, Yuji Ito <y...@imagine-orb.com> wrote: >>> >>> Hi, >>> >>> I'm testing Cassandra CAS operation. >>> >>> Can a read operation read uncommitted data which is being updated by CAS >>> in the following case? >>> >>> I use Cassandra 2.2.6. >>> There are 3 nodes (A, B and C) in a cluster. >>> Replication factor of keyspace is 3. >>> CAS operation on node A starts to update row X (updating the value in row >>> from 0 to 1). >>> >>> 1. prepare/promise phase succeeds on node A >>> 2. node C is down >>> 3. read/results phase in node A sends read requests to node B and C and >>> waits for read responses from them. >>> 4. (unrelated) read operation (CL: SERIAL) reads the same row X and gets >>> the value "1" in the row!! >>> 5. read/results phase fails by ReadTimeoutException caused by failure of >>> node C >>> >>> Thanks, >>> Yuji Ito >> >> >> >> >> -- >> Tyler Hobbs >> DataStax > >
