[
https://issues.apache.org/jira/browse/CASSANDRA-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien Lambert updated CASSANDRA-4598:
--------------------------------------
Description:
On a 2 node-cluster, if the two tokens are close enough, the ownership
information displayed will be 0.00% for each, instead of ~0% for one and ~100%
for the other. The number of replicas displayed is then 0, even if you have
more.
Reproduce:
- Create a 2-node cluster, using Murmur3Partitioner
- Move the tokens to two consecutive values
- Display ring with nodetool
Problem:
This line causing this problem is in {{describeOwnership()}} of
{{Murmur3Partitioner.java}} (lines 117 and 123):
{{float age = ((ti - tim1 + ri) % ri) / ri;}}
If {{ti - tim1}} (the difference of the two consecutive tokens) is too small,
then the precision of the float isn't enough to represent the exact numbers
(because {{ri}}, the total range of the ring, is a very big number).
For example, {{(float) (ri + 1) = (float) (ri - 1) = (float) ri =
9.223372E18}}, so that {{((ri+1)%ri)/ri = ((ri-1)%ri)/ri = (ri%ri)/ri = 0}}.
Whereas with a correct precision, the exact value for {{(ri-1)%ri}} should be
{{ri-1}} and {{(ri-1)/ri ~ 1.0 (100%)}} instead of 0%.
Also, as the number of replica is determined by NodeCmd using the ownership
percentages, it is wrong too.
Solution:
We might want to use BigInteger or BigDecimal somewhere?
was:
On a 2 node-cluster, if the two tokens are close enough, the ownership
information displayed will be 0.00% for each, instead of ~0% for one and ~100%
for the other.
Reproduce:
- Create a 2-node cluster, using Murmur3Partitioner
- Move the tokens to two consecutive values
- Display ring with nodetool
Problem:
This line causing this problem is in {{describeOwnership()}} of
{{Murmur3Partitioner.java}} (lines 117 and 123):
{{float age = ((ti - tim1 + ri) % ri) / ri;}}
If {{ti - tim1}} (the difference of the two consecutive tokens) is too small,
then the precision of the float isn't enough to represent the exact numbers
(because {{ri}}, the total range of the ring, is a very big number).
For example, {{(float) (ri + 1) = (float) (ri - 1) = (float) ri =
9.223372E18}}, so that {{((ri+1)%ri)/ri = ((ri-1)%ri)/ri = (ri%ri)/ri = 0}}.
Whereas with a correct precision, the exact value for {{(ri-1)%ri}} should be
{{ri-1}} and {{(ri-1)/ri ~ 1.0 (100%)}} instead of 0%.
Solution:
We might want to use BigInteger or BigDecimal somewhere?
> describeOwnership() in Murmur3Partitioner.java doesn't work for close tokens
> ----------------------------------------------------------------------------
>
> Key: CASSANDRA-4598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4598
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.2.0
> Reporter: Julien Lambert
> Priority: Minor
>
> On a 2 node-cluster, if the two tokens are close enough, the ownership
> information displayed will be 0.00% for each, instead of ~0% for one and
> ~100% for the other. The number of replicas displayed is then 0, even if you
> have more.
> Reproduce:
> - Create a 2-node cluster, using Murmur3Partitioner
> - Move the tokens to two consecutive values
> - Display ring with nodetool
> Problem:
> This line causing this problem is in {{describeOwnership()}} of
> {{Murmur3Partitioner.java}} (lines 117 and 123):
> {{float age = ((ti - tim1 + ri) % ri) / ri;}}
> If {{ti - tim1}} (the difference of the two consecutive tokens) is too small,
> then the precision of the float isn't enough to represent the exact numbers
> (because {{ri}}, the total range of the ring, is a very big number).
> For example, {{(float) (ri + 1) = (float) (ri - 1) = (float) ri =
> 9.223372E18}}, so that {{((ri+1)%ri)/ri = ((ri-1)%ri)/ri = (ri%ri)/ri = 0}}.
> Whereas with a correct precision, the exact value for {{(ri-1)%ri}} should be
> {{ri-1}} and {{(ri-1)/ri ~ 1.0 (100%)}} instead of 0%.
> Also, as the number of replica is determined by NodeCmd using the ownership
> percentages, it is wrong too.
> Solution:
> We might want to use BigInteger or BigDecimal somewhere?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
