why repair again? We block until the consistency constraint is met. Then the latest version is returned and repair is done asynchronously if any mismatch. We may retry read if fewer columns than required are returned.
On Wed, Oct 24, 2012 at 6:10 AM, shankarpnsn <shankarp...@gmail.com> wrote: > Hello, > > This conversation precisely targets a question that I had been having for a > while - would be grateful if you someone cloud clarify it a little further: > > Considering the case of a "repair" created due to a consistency constraint > (first case in the discussion above), would the following interpretation be > correct ? > > 1. A digest mismatch exception is raised even if one among the many > responses (even if consistency is met on an out-of-date value, say by > virtue > of timestamp). > 2. A read is initiated by the callback to fetch data from all replicas > 3. Resolve() is invoked to find the deltas for each replica that was out of > date. > 4. ReadRepair is scheduled to the above replicas. > 5. Perform a normal read and check if this meets the consistency > constraints. Mismatches would trigger a repair again. > > Assuming the above is true, would the mutations in step 4 and the read in > step 5 happen in parallel ? In other words, would the time taken by the > read > correction be the round trip between the coordinator and its farthest > replica that meets the consistency constraint. > > Thanks, > Shankar > > > > -- > View this message in context: > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/What-does-ReadRepair-exactly-do-tp7583261p7583352.html > Sent from the cassandra-u...@incubator.apache.org mailing list archive at > Nabble.com. >
