> Last time I checked, this was not true for batch writes. The row
> mutations were started sequentially (ie, for each mutation check
> availability, then kick off an aynchronous write), so it was possible
> for the first to succeed, and the second to fail with an
> UnavailableException.
>
Thats a
On Fri, Aug 17, 2012 at 8:00 AM, Nick Bailey wrote:
> This is actually incorrect. If you get an UnavailableException, the
> write was rejected by the coordinator and was not written anywhere.
Last time I checked, this was not true for batch writes. The row
mutations were started sequentially (ie,
Thanks Nick for your answers. The blog post is very well written and was
much needed i guess.
On Fri, Aug 17, 2012 at 8:30 PM, Nick Bailey wrote:
> This blog post should help:
>
> http://www.datastax.com/dev/blog/how-cassandra-deals-with-replica-failure
>
> But to answer your question:
>
> >> Un
This blog post should help:
http://www.datastax.com/dev/blog/how-cassandra-deals-with-replica-failure
But to answer your question:
>> UnavailableException is bit tricky. It means, that not all replicas
>> required by CL received update. Actually you do not know, whenever update
>> was stored or
Does this mean that the coordinator sends requests to all nodes, even when
it knows that sufficient number of nodes are not available, via gossip?
On Fri, Aug 17, 2012 at 4:49 PM, Maciej Miklas wrote:
> UnavailableException is bit tricky. It means, that not all replicas
> required by CL receive
UnavailableException is bit tricky. It means, that not all replicas
required by CL received update. Actually you do not know, whenever update
was stored or not, and actually what went wrong.
This is the case, why writing with CL.ALL might get problematic. It is
enough, that only one replica is off
