You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jeremy Hanna (JIRA)" <ji...@apache.org> on 2010/07/09 19:04:50 UTC
[jira] Created: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Push replication factor down to the replication strategy
--------------------------------------------------------
Key: CASSANDRA-1263
URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
Project: Cassandra
Issue Type: Task
Components: Core
Reporter: Jeremy Hanna
Assignee: Jeremy Hanna
Priority: Minor
Fix For: 0.7
Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1263:
--------------------------------------
Fix Version/s: 0.8
(was: 0.7.0)
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jeremy Hanna
> Priority: Minor
> Fix For: 0.8
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923104#action_12923104 ]
Jonathan Ellis commented on CASSANDRA-1263:
-------------------------------------------
bq. the only references to [RF] outside the Strategy classes themselves are a couple assert statements that could easily be cleaned up.
[reply-to-self] Actually I don't think this is true, wanting to know the total number of copies of the data is a reasonable thing to do.
bq. All code that asks for RF should really be asking for strategy.getReplicationFactor().
Agreed.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923103#action_12923103 ]
Jonathan Ellis commented on CASSANDRA-1263:
-------------------------------------------
bq. We need to make sure they give us a replication_factor.
Right.
bq. We should not verify arbitrary key/values in strategy_opts because that is FAR messier than the current solution
Wrong. strategy_ops is by definition he only place for per-strategy options, and replication_factor is already a per-strategy option. The problem is the current KsDef doesn't acknowledge that yet. This is a bug.
Classes implementing ARS should take whatever replication configuration necessary from strategy_options and store that state at construction time, the way NTS already does.
ReplicationFactor is an implementation detail of some strategies, NOT something we should expose as integral to all of them because we have proof that it's not. If you look at the code the only references it outside the Strategy classes themselves are a couple assert statements that could easily be cleaned up.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jon Hermes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jon Hermes updated CASSANDRA-1263:
----------------------------------
Attachment: 1263-incomplete.txt
Rep_factor has been wiped off the face of the earth, and the engine for its usage was nicely wrapped up in DD.getReplicationFactor(), so now that just gets the strat for the keyspace and calls strat.getRF().
Converter does the right thing, and the CLI still does the right thing.
ConfigurationException throwing/handling still needs to be glued onto strategies (most likely in ARS).
The problem right now is that YAML is being finicky, and is either trying to load a map as a non-collection, or it tries to expand the map in place and check for a property on RawKeyspace for every arbitrary strat_opt.
In any event, I'm attaching the partial patch now to make sure it doesn't get lost in the revision-shuffle (and because it's more code than I thought it would be). The best time to finish this may be in a larger YAML/config fix.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
> Attachments: 1263-incomplete.txt
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921579#action_12921579 ]
Jonathan Ellis commented on CASSANDRA-1263:
-------------------------------------------
in my mind what this ticket means is NTS should have its per-dc options and the other RS should have replication_factor.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893673#action_12893673 ]
Jeremy Hanna commented on CASSANDRA-1263:
-----------------------------------------
This would make it a lot easier/natural to enforce the replication factor down to the keyspace. For example in the DatacenterShardStrategy, when the RF per datacenter is specified - it's easier to enforce that the total RF is the same as the sum of the DCs RF.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jeremy Hanna
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923122#action_12923122 ]
Jonathan Ellis commented on CASSANDRA-1263:
-------------------------------------------
bq. Because user-def strats can require arbitrary opts, I can't easily verify that they exist
you shouldn't be trying to. instead you should merely instantiate the strategy, which should be responsible for throwing ConfigurationException if it borks.
bq. Furthermore, I have to call getRF() is every place in the code that we ask for the instance RF, and I can't guarantee that getRF() is non-trivial (and it runs in tight loops).
Add a docstring saying that implementors of getRF (which becomes abstract) are responsible for making it fast, which may or may not include caching it.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CASSANDRA-1263) Push replication
factor down to the replication strategy
Posted by "Jon Hermes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923119#action_12923119 ]
Jon Hermes edited comment on CASSANDRA-1263 at 10/20/10 3:35 PM:
-----------------------------------------------------------------
So on keyspace instantiation, I expect some set of opts for a given strategy to exist, otherwise calling getRF() will explode. Because user-def strats can require arbitrary opts, I can't easily verify that they exist*, and I can't guarantee that system_create_keyspace() will not explode (which is a non-desired side effect).
Furthermore, I have to call getRF() in every place in the code that we ask for the instance RF, and I can't guarantee that getRF() is non-trivial (and it runs in tight loops). Caching the getRF() call is a hefty chunk of code, and then I need to reset the cached value if the KSMD changes during runtime, which is another hefty chunk of code.
*It is possible to make every strat implement an interface method for `List<String> returnRequiredOpts()`.
was (Author: jhermes):
So on keyspace instantiation, I expect some set of opts for a given strategy to exist, otherwise calling getRF() will explode. Because user-def strats can require arbitrary opts, I can't easily verify that they exist*, and I can't guarantee that system_create_keyspace() will not explode (which is a non-desired side effect).
Furthermore, I have to call getRF() is every place in the code that we ask for the instance RF, and I can't guarantee that getRF() is non-trivial (and it runs in tight loops). Caching the getRF() call is a hefty chunk of code, and then I need to reset the cached value if the KSMD changes during runtime, which is another hefty chunk of code.
*It is possible to make every strat implement an interface method for `List<String> returnRequiredOpts()`.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna reassigned CASSANDRA-1263:
---------------------------------------
Assignee: (was: Jeremy Hanna)
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jon Hermes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923133#action_12923133 ]
Jon Hermes commented on CASSANDRA-1263:
---------------------------------------
Agreed and agreed.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CASSANDRA-1263) Push replication
factor down to the replication strategy
Posted by "Jon Hermes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923119#action_12923119 ]
Jon Hermes edited comment on CASSANDRA-1263 at 10/20/10 3:36 PM:
-----------------------------------------------------------------
So on keyspace instantiation, I expect some set of opts for a given strategy to exist, otherwise calling getRF() will explode. Because user-def strats can require arbitrary opts, I can't easily verify that they exist*, and I can't guarantee that system_create_keyspace() will not explode (which is a non-desired side effect).
Furthermore, I have to call getRF() in every place in the code that we ask for the instance RF, and I can't guarantee that getRF() is non-trivial (and it runs in tight loops). -Caching the getRF() call is a hefty chunk of code, and then I need to reset the cached value if the KSMD changes during runtime, which is another hefty chunk of code.- < This can be done in the current place of replication_factor, so it's not painful.
*It is possible to make every strat implement an interface method for `List<String> returnRequiredOpts()`.
was (Author: jhermes):
So on keyspace instantiation, I expect some set of opts for a given strategy to exist, otherwise calling getRF() will explode. Because user-def strats can require arbitrary opts, I can't easily verify that they exist*, and I can't guarantee that system_create_keyspace() will not explode (which is a non-desired side effect).
Furthermore, I have to call getRF() in every place in the code that we ask for the instance RF, and I can't guarantee that getRF() is non-trivial (and it runs in tight loops). Caching the getRF() call is a hefty chunk of code, and then I need to reset the cached value if the KSMD changes during runtime, which is another hefty chunk of code.
*It is possible to make every strat implement an interface method for `List<String> returnRequiredOpts()`.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1263:
--------------------------------------
Fix Version/s: (was: 0.7.0)
0.8
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.8
>
> Attachments: 1263-incomplete.txt
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jon Hermes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923092#action_12923092 ]
Jon Hermes commented on CASSANDRA-1263:
---------------------------------------
We need to make sure they give us a replication_factor. We cannot make it required on the def because not all strategies use a static type to give us that information. We should not verify arbitrary key/values in strategy_opts because that is FAR messier than the current solution, and doesn't handle user-created strategies at all.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1263:
--------------------------------------
Fix Version/s: (was: 0.8)
0.7.0
Assignee: Jon Hermes (was: Jeremy Hanna)
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CASSANDRA-1263) Push replication
factor down to the replication strategy
Posted by "Jon Hermes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923092#action_12923092 ]
Jon Hermes edited comment on CASSANDRA-1263 at 10/20/10 3:04 PM:
-----------------------------------------------------------------
-We need to make sure they give us a replication_factor. We cannot make it required on the def because not all strategies use a static type to give us that information. We should not verify arbitrary key/values in strategy_opts because that is FAR messier than the current solution, and doesn't handle user-created strategies at all.-
All code that asks for RF should really be asking for strategy.getReplicationFactor().
was (Author: jhermes):
We need to make sure they give us a replication_factor. We cannot make it required on the def because not all strategies use a static type to give us that information. We should not verify arbitrary key/values in strategy_opts because that is FAR messier than the current solution, and doesn't handle user-created strategies at all.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna reassigned CASSANDRA-1263:
---------------------------------------
Assignee: Jeremy Hanna
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jeremy Hanna
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1263) Push replication factor down to
the replication strategy
Posted by "Jon Hermes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923119#action_12923119 ]
Jon Hermes commented on CASSANDRA-1263:
---------------------------------------
So on keyspace instantiation, I expect some set of opts for a given strategy to exist, otherwise calling getRF() will explode. Because user-def strats can require arbitrary opts, I can't easily verify that they exist*, and I can't guarantee that system_create_keyspace() will not explode (which is a non-desired side effect).
Furthermore, I have to call getRF() is every place in the code that we ask for the instance RF, and I can't guarantee that getRF() is non-trivial (and it runs in tight loops). Caching the getRF() call is a hefty chunk of code, and then I need to reset the cached value if the KSMD changes during runtime, which is another hefty chunk of code.
*It is possible to make every strat implement an interface method for `List<String> returnRequiredOpts()`.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.