that makes sense. thanks! On Apr 7, 2011, at 8:36 AM, Stephen Connolly wrote:
> also there is a configuration parameter that controls the probability of any > read request triggering a read repair > > - Stephen > > --- > Sent from my Android phone, so random spelling mistakes, random nonsense > words and other nonsense are a direct result of using swype to type on the > screen > > On 7 Apr 2011 07:35, "Stephen Connolly" <stephen.alan.conno...@gmail.com> > wrote: > > as I understand, the read repair is a background task triggered by the read > > request, but once the consistency requirement has been met you will be given > > a response. > > > > the coordinator at CL.ONE is allowed to return your responce once it has one > > response (empty or not) from any replica. if the first response is empty, > > you get null > > > > - Stephen > > > > --- > > Sent from my Android phone, so random spelling mistakes, random nonsense > > words and other nonsense are a direct result of using swype to type on the > > screen > > On 7 Apr 2011 00:10, "Jonathan Colby" <jonathan.co...@gmail.com> wrote: > >> > >> Let's say you have RF of 3 and a write was written to 2 nodes. 1 was not > > written because the node had a network hiccup (but came back online again). > >> > >> My question is, if you are reading a key with a CL of ONE, and you happen > > to land on that node that didn't get the write, will the read fail > > immediately? > >> > >> Or, would read repair check the other replicas and fetch the correct data > > from the other node(s)? > >> > >> Secondly, is read repair done according to the consistency level, or is > > read repair an independent configuration setting that can be turned on/off. > >> > >> There was a recent thread about a different variation of my question, but > > went into very technical details, so I didn't want to hijack that thread.
