[
https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881880#action_12881880
]
Gary Dusbabek commented on CASSANDRA-1066:
------------------------------------------
* CS should use SS.instance.getTokenMetadata() instead of creating a new one.
* the factory calls the old implicit constructor and then init(). Is this an
improvement over just adding a map to the constructor args, and then having the
constructor (if needed) do the work in init? Having an init() method opens up
the API to abuse (when should[n't] I call init, etc.?). I'm in favor of just
amending the implicit constructors.
* fix all the todos. :)
> DatacenterShardStrategy needs enforceable and keyspace based RF
> ---------------------------------------------------------------
>
> Key: CASSANDRA-1066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1066
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jeremy Hanna
> Priority: Minor
> Fix For: 0.7
>
> Attachments: 1066-changes-patch.txt
>
>
> Currently, the DatacenterShardStrategy reads in a properties file -
> datacenters.properties - to get a per-datacenter replication factor. So any
> keyspace that is using the DSS in the cluster is using that same properties
> file to configure its replication factor. The implementation doesn't take
> into account the per-keyspace replication factor, but it is assumed that the
> sum of all the datacenter RF values equals the per-keyspace replication value
> that is part of the keyspace metadata.
> It seems that an improvement could be two-fold:
> 1. Enforce the replication factor for the keyspace as always equal the sum of
> all the datacenter RF values. Otherwise, if they aren't equal, bad things
> (tm) can happen.
> 2. Make the datacenter RF values part of the keyspace metadata rather than a
> global value. Again, currently if any keyspace in the cluster is configured
> to use DSS, it will be using the global DC RF values found in the properties
> file. An improvement could be to instead of having the properties file,
> configure that on a per keyspace basis. That would make the cluster more
> multi-tenant friendly so it could be flexible with multiple keyspaces.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
