[
https://issues.apache.org/jira/browse/CASSANDRA-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-6289:
-----------------------------------------
Assignee: Mikhail Stepura
> 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
> Fix For: 1.2.12
>
>
> 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)
