[
https://issues.apache.org/jira/browse/CASSANDRA-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15801192#comment-15801192
]
Stefan Podkowinski commented on CASSANDRA-13052:
------------------------------------------------
Which repairs are affected? The tree depth will effectively calculated as
{{min(log(partitions), 20)}}, ie. the depth will increase logarithmic until
capped at 20. In the worst case scenario, the described bug will happen when
the repaired token range will be less than 2^20. Using the Murmur3Partitioner,
this is still less than individual ranges created by using vnodes in a large
cluster {{(2^64 / (vnodes * nodes))}}. As vnodes are created based on random
values, there's still a chance that two vnodes are close enough together to get
affected by this bug regulary. Although this requires a fairly large amount of
partitions and I'm wondering if it would be practically possible to run repairs
in this setup anyways. More likely this could be an issue for tools that would
work by calculating their own (smaller) ranges instead of running repairs based
on (v)nodes.
> Repair process is violating the start/end token limits for small ranges
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-13052
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13052
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
> Environment: We tried this in 2.0.14 and 3.9, same bug.
> Reporter: Cristian P
> Assignee: Stefan Podkowinski
> Attachments: ccm_reproduce-13052.txt, system-dev-debug-13052.log
>
>
> We tried to do a single token repair by providing 2 consecutive token values
> for a large column family. We soon notice heavy streaming and according to
> the logs the number of ranges streamed was in thousands.
> After investigation we found a bug in the two partitioner classes we use
> (RandomPartitioner and Murmur3Partitioner).
> The midpoint method used by MerkleTree.differenceHelper method to find ranges
> with differences for streaming returns abnormal values (way out of the
> initial range requested for repair) if the repair requested range is small (I
> expect smaller than 2^15).
> Here is the simple code to reproduce the bug for Murmur3Partitioner:
> Token left = new Murmur3Partitioner.LongToken(123456789L);
> Token right = new Murmur3Partitioner.LongToken(123456789L);
> IPartitioner partitioner = new Murmur3Partitioner();
> Token midpoint = partitioner.midpoint(left, right);
> System.out.println("Murmur3: [ " + left.getToken() + " : " +
> midpoint.getToken() + " : " + right.getToken() + " ]");
> The output is:
> Murmur3: [ 123456789 : -9223372036731319019 : 123456789 ]
> Note that the midpoint token is nowhere near the suggested repair range. This
> will happen if during the parsing of the tree (in
> MerkleTree.differenceHelper) in search for differences there isn't enough
> tokens for the split and the subrange becomes 0 (left.token=right.token) as
> in the above test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
