[jira] [Updated] (CASSANDRA-13052) Repair process is violating the start/end token limits for small ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-13052:
---
Resolution: Fixed
Fix Version/s: 4.0
3.11.0
3.0.14
Status: Resolved (was: Ready to Commit)
Merged as 38725802456dfcfcc2584cdfd061ac22215c2dfb to 3.0 -> 3.11 -> 4.0
> 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
> Fix For: 3.0.14, 3.11.0, 4.0
>
> Attachments: 13052-2.1.patch, 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.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13052) Repair process is violating the start/end token limits for small ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-13052:
Status: Ready to Commit (was: Patch Available)
> 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: 13052-2.1.patch, 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.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13052) Repair process is violating the start/end token limits for small ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-13052:
---
Status: Patch Available (was: In Progress)
> 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: 13052-2.1.patch, 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)
[jira] [Updated] (CASSANDRA-13052) Repair process is violating the start/end token limits for small ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-13052:
---
Attachment: 13052-2.1.patch
> 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: 13052-2.1.patch, 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)
[jira] [Updated] (CASSANDRA-13052) Repair process is violating the start/end token limits for small ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-13052:
---
Attachment: (was: system-dev-debug-13052.log)
> 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)
[jira] [Updated] (CASSANDRA-13052) Repair process is violating the start/end token limits for small ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-13052:
---
Attachment: system-dev-debug-13052.log
> 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,
> 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)
[jira] [Updated] (CASSANDRA-13052) Repair process is violating the start/end token limits for small ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-13052:
---
Priority: Major (was: Minor)
> 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
> 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)
[jira] [Updated] (CASSANDRA-13052) Repair process is violating the start/end token limits for small ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-13052:
---
Attachment: system-dev-debug-13052.log
ccm_reproduce-13052.txt
> 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
>Priority: Minor
> 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)
