In the case described below if less than CL nodes respond in rpc_timeout (from conf yaml) the client will get a timeout error. I think most higher level clients will automatically retry in this case.
If there are not enough nodes to start the request you will get an Unavailable exception. Again the client can retry safely. Aaron On 23/02/2011, at 8:07 PM, Dave Revell <d...@meebo-inc.com> wrote: > Ritesh, > > There is no commit protocol. Writes may be persisted on some replicas even > though the quorum fails. Here's a sequence of events that shows the "problem:" > > 1. Some replica R fails, but recently, so its failure has not yet been > detected > 2. A client writes with consistency > 1 > 3. The write goes to all replicas, all replicas except R persist the write to > disk > 4. Replica R never responds > 5. Failure is returned to the client, but the new value is still in the > cluster, on all replicas except R. > > Something very similar could happen for CL QUORUM. > > This is a conscious design decision because a commit protocol would > constitute tight coupling between nodes, which goes against the Cassandra > philosophy. But unfortunately you do have to write your app with this case in > mind. > > Best, > Dave > > On Tue, Feb 22, 2011 at 8:22 PM, tijoriwala.ritesh > <tijoriwala.rit...@gmail.com> wrote: > > Hi, > I wanted to get details on how does cassandra do synchronous writes to W > replicas (out of N)? Does it do a 2PC? If not, how does it deal with > failures of of nodes before it gets to write to W replicas? If the > orchestrating node cannot write to W nodes successfully, I guess it will > fail the write operation but what happens to the completed writes on X (W > > X) nodes? > > Thanks, > Ritesh > -- > View this message in context: > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/How-does-Cassandra-handle-failure-during-synchronous-writes-tp6055152p6055152.html > Sent from the cassandra-u...@incubator.apache.org mailing list archive at > Nabble.com. >
