Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of coolmohitz@gmail.com designates
 209.85.212.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALk=J58v1j+=ZWGUbVH_5b1iPxNV1yQqTXeoRBp_HZA+OjF-bg@mail.gmail.com>
References: 
 <CAHzZuFous=Qpdy6DhWyfV7Q2os5wjW48dpakgQVms+K93fj1BQ@mail.gmail.com>
	<CALk=J58v1j+=ZWGUbVH_5b1iPxNV1yQqTXeoRBp_HZA+OjF-bg@mail.gmail.com>
Date: Fri, 17 Aug 2012 19:57:59 +0530
Message-ID: 
 <CAHzZuFpRHOF8x-v619ufHUj+Wf7Bz9is6Bwsjbp3iLZpLEiYGA@mail.gmail.com>
Subject: Re: Understanding UnavailableException
From: Mohit Agarwal <coolmohitz@gmail.com>
To: user@cassandra.apache.org, mac.miklas@gmail.com
Content-Type: multipart/alternative; boundary=f46d04428cc87d397d04c776f77a

--f46d04428cc87d397d04c776f77a
Content-Type: text/plain; charset=ISO-8859-1

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 <mac.miklas@gmail.com> wrote:

> 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-line and you will get exception.
> Remember also, that CL.ALL means, all replicas in all Data Centers - not
> only local DC. Writing with QUORUM_LOCAL could be better idea.
>
> There is only one CL, where exception guarantees, that data was really not
> stored: CL.ANY with hinted handoff enabled.
>
> One more thing: write goes always to all replicas independent from
> provided CL. Client request blocks only until required replicas respond -
> however this response is asynchronous. This means, when you write with
> lower CL, replicas will get data with the same speed, only your client does
> not wait for acknowledgment from all of them.
>
> Ciao,
> Maciej
>
>
>
> On Fri, Aug 17, 2012 at 11:07 AM, Mohit Agarwal <coolmohitz@gmail.com>wrote:
>
>> Hi guys,
>>
>> I am trying to understand what happens when an UnavailableException is
>> thrown.
>>
>> a) Suppose we are doing a ConsistencyLevel.ALL write on a 3 node cluster.
>> My understanding is that if one of the nodes is down and the coordinator
>> node is aware of that(through gossip), then it will respond to the request
>> with an UnavailableException. Is this correct?
>>
>> b) What happens if the coordinator isn't aware of a node being down and
>> sends the request to all the nodes and never hears back from one of the
>> node. Would this result in a TimedOutException or a UnavailableException?
>>
>> c) I am trying to understand the cases where the client receives an
>> error, but data could have been inserted into Cassandra. One such case is
>> the TimedOutException. Are there any other situations like these?
>>
>> Thanks,
>> Mohit
>>
>
>

--f46d04428cc87d397d04c776f77a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Does this mean that the coordinator sends requests to all nodes, even when =
it =A0knows that sufficient number of nodes are not available, via gossip?<=
div><br><div class=3D"gmail_quote">On Fri, Aug 17, 2012 at 4:49 PM, Maciej =
Miklas <span dir=3D"ltr">&lt;<a href=3D"mailto:mac.miklas@gmail.com" target=
=3D"_blank">mac.miklas@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">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.<br>
<br>This is the case, why writing with CL.ALL might get problematic. It is =
enough, that only one replica is off-line and you will get exception. Remem=
ber also, that CL.ALL means, all replicas in all Data Centers - not only lo=
cal DC. Writing with QUORUM_LOCAL could be better idea.<br>

<br>There is only one CL, where exception guarantees, that data was really =
not stored: CL.ANY with hinted handoff enabled.<br><br>One more thing: writ=
e goes always to all replicas independent from provided CL. Client request =
blocks only until required replicas respond - however this response is asyn=
chronous. This means, when you write with lower CL, replicas will get data =
with the same speed, only your client does not wait for acknowledgment from=
 all of them.<br>

<br>Ciao,<br>Maciej<div class=3D"HOEnZb"><div class=3D"h5"><br><br><br><div=
 class=3D"gmail_quote">On Fri, Aug 17, 2012 at 11:07 AM, Mohit Agarwal <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:coolmohitz@gmail.com" target=3D"_blank"=
>coolmohitz@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi guys,=A0<div><br></div><div>I am trying t=
o understand what happens when an UnavailableException is thrown.=A0</div><=
div>

<br></div><div>a) Suppose we are doing a ConsistencyLevel.ALL write on a 3 =
node cluster. My understanding is that if one of the nodes is down and the =
coordinator node is aware of that(through gossip), then it will respond to =
the request with an UnavailableException. Is this correct?</div>


<div><br></div><div>b) What happens if the coordinator isn&#39;t aware of a=
 node being down and sends the request to all the nodes and never hears bac=
k from one of the node. Would this result in a TimedOutException or a Unava=
ilableException?=A0</div>


<div><br></div><div>c) I am trying to understand the cases where the client=
 receives an error, but data could have been inserted into Cassandra. One s=
uch case is the TimedOutException. Are there any other situations like thes=
e?=A0</div>


<div><br></div><div>Thanks,</div><div>Mohit</div>
</blockquote></div><br>
</div></div></blockquote></div><br></div>

--f46d04428cc87d397d04c776f77a--