Yes, all this starts because of the call to filter.collateColumns()… The ColumnFamily is an implementation of o.a.c.dbAbstractColumnContainer , the methods to add columns on that interface pass through to an implementation of ISortedColumns.
The implementations of ISortedColumns, e.g. ArrayBackedSortedColumns, will call reconcile() on the IColumn if they need to. Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 23/10/2012, at 4:45 AM, Manu Zhang <owenzhang1...@gmail.com> wrote: > Is it through filter.collateColumns(resolved, iters, Integer.MIN_VALUE) and > then MergeIterator.get(toCollate, fcomp, reducer) but I don't know what > happens hereafter? How is reconcile exactly been called? > > On Mon, Oct 22, 2012 at 6:49 AM, aaron morton <aa...@thelastpickle.com> wrote: > There are two processes in cassandra that trigger Read Repair like behaviour. > > During a DigestMismatchException is raised if the responses from the replicas > do not match. In this case another read is run that involves reading all the > data. This is the CL level agreement kicking in. > > The other "Read Repair" is the one controlled by the "read_repair_chance". > When RR is active on a request ALL up replicas are involved in the read. When > RR is not active only CL replicas are involved. When test for CL agreement > occurs synchronously to the request; the RR check waits asynchronously to the > request for all nodes in the request to return. It then checks for > consistency and repairs differences. > >> From looking at the source code, I do not understand how this set is built >> and I do not understand how the reconciliation is executed. > When a DigestMismatch is detected a read is run using RepairCallback. The > callback will call the RowRepairResolver.resolve() when enough responses have > been collected. > > resolveSuperset() picks one response to the baseline, and then calls delete() > to apply row level deletes from the other responses (ColumnFamily's). It > collects the other CF's into an iterator with a filter that returns all > columns. The columns are then applied to the baseline CF which may result in > reconcile() being called. > > reconcile() is used when a AbstractColumnContainer has two versions of a > column and it wants to only have one. > > RowRepairResolve.scheduleRepairs() works out the delta for each node by > calling ColumnFamily.diff(). The delta is then sent to the appropriate node. > > > Hope that helps. > > > ----------------- > Aaron Morton > Freelance Developer > @aaronmorton > http://www.thelastpickle.com > > On 19/10/2012, at 6:33 AM, Markus Klems <markuskl...@gmail.com> wrote: > >> Hi guys, >> >> I am looking through the Cassandra source code in the github trunk to better >> understand how Cassandra's fault-tolerance mechanisms work. Most things make >> sense. I am also aware of the wiki and DataStax documentation. However, I do >> not understand what read repair does in detail. The method >> RowRepairResolver.resolveSuperset(Iterable<ColumnFamily> versions) seems to >> do the trick of merging conflicting versions of column family replicas and >> builds the set of columns that need to be "repaired". From looking at the >> source code, I do not understand how this set is built and I do not >> understand how the reconciliation is executed. ReadRepair does not seem to >> trigger a Column.reconcile() to reconcile conflicting column versions on >> different servers. Does it? >> >> If this is not what read repair does, then: What kind of inconsistencies are >> resolved by read repair? And: How are the inconsistencies resolved? >> >> Could someone give me a hint? >> >> Thanks so much, >> >> -Markus > >
