cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Podkowinski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13052) Repair process is violating the start/end token limits for small ranges
Date Thu, 05 Jan 2017 12:01:06 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15801182#comment-15801182
] 

Stefan Podkowinski commented on CASSANDRA-13052:
------------------------------------------------

The issue is not that ranges will be added multiple times, but the fact that the added range
has an equal start and endpoint and is thus invalid by definition. Things starts to go awry
in the normalize method, which will handle the range as a wrap-around value and turns the
specified range into another range of (MINIMUM, MINIMUM). This range is handled special in
some occassions and seems to cause {{DataTracker.sstablesInBounds()}} return basically all
sstables. Based on those tables, the SSTable section calculation will return all content from
each SSTable as well and so it looks to me that this will cause streaming of all data. 



> 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)

Mime
View raw message