cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2610) Have the repair of a range repair *all* the replica for that range
Date Thu, 01 Sep 2011 16:46:10 GMT


Sylvain Lebresne commented on CASSANDRA-2610:

bq. use concurrent structures instead of synchronized

I think this doesn't work, or need modifications elsewhere. The synchronized was making sure
that for a given job, there would be one and only one call to addTree that returns 0 (otherwise
we'll generate twice the differencers in that case). The synchronized was to make the 'remove
then return length' atomic, more than to protect the access to the structure. completedSynchronization
does have the same problem even though in that case the consequence is benign, we'll just
print the sync message twice (it's still less good than with synchronized).

Also, without having ran it, I'm not sure the change to the test works, because since REMOTE
won't ever send a merkle tree, the differencers won't ever be generated. But to be honest,
this test is really not very useful and I would be fine with just removing it instead of faking
things to a point where it doesn't really test anything.

> Have the repair of a range repair *all* the replica for that range
> ------------------------------------------------------------------
>                 Key: CASSANDRA-2610
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 0.8 beta 1
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.0
>         Attachments: 0001-Make-repair-repair-all-hosts-v2.patch, 0001-Make-repair-repair-all-hosts.patch,
0002-Cleanup-log-messages-v2.patch, 0003-cleanup-and-fix-private-reference.patch
>   Original Estimate: 8h
>  Remaining Estimate: 8h
> Say you have a range R whose replica for that range are A, B and C. If you run repair
on node A for that range R, when the repair end you only know that A is fully repaired. B
and C are not. That is B and C are up to date with A before the repair, but are not up to
date with one another.
> It makes it a pain to schedule "optimal" cluster repairs, that is repairing a full cluster
without doing work twice (because you would have still have to run a repair on B or C, which
will make A, B and C redo a validation compaction on R, and with more replica it's even more
> However it is fairly easy during the first repair on A to have him compare all the merkle
trees, i.e the ones for B and C, and ask to B or C to stream between them whichever the differences
they have. 

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message