[ https://issues.apache.org/jira/browse/CASSANDRA-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13829297#comment-13829297 ]
Brandon Williams commented on CASSANDRA-6289: --------------------------------------------- +1 > Murmur3Partitioner doesn't yield proper ownership calculation > ------------------------------------------------------------- > > Key: CASSANDRA-6289 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6289 > Project: Cassandra > Issue Type: Bug > Components: Tools > Reporter: Jackson Chung > Assignee: Mikhail Stepura > Priority: Minor > Fix For: 1.2.13 > > Attachments: 6289-v2.txt, cassandra-1.2-6289.patch > > > In a new 1.2 install with Murmur3 as default, I setup a test cluster with > N=RF=3 for the cluster size and RF for a keyspace > but when I look at the ring output (with the keyspace name), to my surprise > it shows RF=2. > Further investigate shows the "total replica" is an addition of the float > value from the effectiveOwnership. But that results in < 1 for the setup: > {panel} > #bean is set to org.apache.cassandra.db:type=StorageService > $>run effectiveOwnership Keyspace1 > #calling operation effectiveOwnership of mbean > org.apache.cassandra.db:type=StorageService > #operation returns: > \{ > /127.0.0.1 = 0.9999989; > /127.0.0.2 = 0.9999989; > /127.0.0.3 = 0.9999989; > \} > {panel} > {panel} > $ ./bin/nodetool -h 0 -p 7100 ring Keyspace1 > Datacenter: datacenter1 > ========== > Replicas: 2 > Address Rack Status State Load Owns > Token > > 3074457345618258602 > 127.0.0.1 rack1 Up Normal 1.02 GB 100.00% > -9223372036854775808 > 127.0.0.2 rack1 Up Normal 996.38 MB 100.00% > -3074457345618258603 > 127.0.0.3 rack1 Up Normal 980.55 MB 100.00% > 3074457345618258602 > {panel} > {panel} > Keyspace: Keyspace1: > Replication Strategy: org.apache.cassandra.locator.SimpleStrategy > Durable Writes: true > Options: [replication_factor:3] > {panel} > The println would simply class the float value to int, so i guess that's > round down. > When using RandomPartitioner, the effectiveOwnership will return 1.0 > So I guess the real question is, is the Murmur3 calculation correct? Or is it > losing precision? If it is correct, then I guess we need to force the float > -> int to round up? (is that even the right thing to do?) -- This message was sent by Atlassian JIRA (v6.1#6144)