[jira] [Updated] (CASSANDRA-2846) Changing replication_factor using update keyspace not working
[
https://issues.apache.org/jira/browse/CASSANDRA-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes updated CASSANDRA-2846:
--
Reviewer: jhermes (was: bcoverston)
Changing replication_factor using update keyspace not working
---
Key: CASSANDRA-2846
URL: https://issues.apache.org/jira/browse/CASSANDRA-2846
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8.1
Environment: A clean 0.8.1 install using the default configuration
Reporter: Jonas Borgström
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.8.2
Attachments: 2846.txt
Unless I've misunderstood the new way to do this with 0.8 I think update
keyspace is broken:
{code}
[default@unknown] create keyspace Test with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
[{replication_factor:1}];
37f70d40-a3e9-11e0--242d50cf1fbf
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] describe keyspace Test;
Keyspace: Test:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:1]
Column Families:
[default@unknown] update keyspace Test with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
[{replication_factor:2}];
489fe220-a3e9-11e0--242d50cf1fbf
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] describe keyspace Test;
Keyspace: Test:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:1]
Column Families:
{code}
Isn't the second describe keyspace supposed to to say
replication_factor:2?
Relevant bits from system.log:
{code}
Migration.java (line 116) Applying migration
489fe220-a3e9-11e0--242d50cf1fbf Update keyspace Testrep
strategy:SimpleStrategy{}durable_writes: true to Testrep
strategy:SimpleStrategy{}durable_writes: true
UpdateKeyspace.java (line 74) Keyspace updated. Please perform any manual
operations
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2846) Changing replication_factor using update keyspace not working
[
https://issues.apache.org/jira/browse/CASSANDRA-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058855#comment-13058855
]
Jon Hermes commented on CASSANDRA-2846:
---
-1, doesn't update strategy_options for KS's that already have SimpleStrategy.
repro:
{noformat}
start 1-node local
stress -o insert -n 1 (create Keyspace1 with SS and RF1)
cli:
[] update keyspace Keyspace1 with strategy_options=[{replication_factor:2}];
{noformat}
Creating a new keyspace (Keyspace2, with default NTS and [{DC1:1}], then
`update keyspace Keyspace2 with
placement_strategy='org.apache.cassandra.locator.SimpleStrategy' and
strategy_options=[{replication_factor:2}];` does work, however.
Changing replication_factor using update keyspace not working
---
Key: CASSANDRA-2846
URL: https://issues.apache.org/jira/browse/CASSANDRA-2846
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8.1
Environment: A clean 0.8.1 install using the default configuration
Reporter: Jonas Borgström
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.8.2
Attachments: 2846.txt
Unless I've misunderstood the new way to do this with 0.8 I think update
keyspace is broken:
{code}
[default@unknown] create keyspace Test with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
[{replication_factor:1}];
37f70d40-a3e9-11e0--242d50cf1fbf
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] describe keyspace Test;
Keyspace: Test:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:1]
Column Families:
[default@unknown] update keyspace Test with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
[{replication_factor:2}];
489fe220-a3e9-11e0--242d50cf1fbf
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] describe keyspace Test;
Keyspace: Test:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:1]
Column Families:
{code}
Isn't the second describe keyspace supposed to to say
replication_factor:2?
Relevant bits from system.log:
{code}
Migration.java (line 116) Applying migration
489fe220-a3e9-11e0--242d50cf1fbf Update keyspace Testrep
strategy:SimpleStrategy{}durable_writes: true to Testrep
strategy:SimpleStrategy{}durable_writes: true
UpdateKeyspace.java (line 74) Keyspace updated. Please perform any manual
operations
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2846) Changing replication_factor using update keyspace not working
[
https://issues.apache.org/jira/browse/CASSANDRA-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058855#comment-13058855
]
Jon Hermes edited comment on CASSANDRA-2846 at 7/1/11 11:21 PM:
--1, doesn't update strategy_options for KS's that already have SimpleStrategy.-
+1, it's good.
was (Author: jhermes):
-1, doesn't update strategy_options for KS's that already have
SimpleStrategy.
repro:
{noformat}
start 1-node local
stress -o insert -n 1 (create Keyspace1 with SS and RF1)
cli:
[] update keyspace Keyspace1 with strategy_options=[{replication_factor:2}];
{noformat}
Creating a new keyspace (Keyspace2, with default NTS and [{DC1:1}], then
`update keyspace Keyspace2 with
placement_strategy='org.apache.cassandra.locator.SimpleStrategy' and
strategy_options=[{replication_factor:2}];` does work, however.
Changing replication_factor using update keyspace not working
---
Key: CASSANDRA-2846
URL: https://issues.apache.org/jira/browse/CASSANDRA-2846
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8.1
Environment: A clean 0.8.1 install using the default configuration
Reporter: Jonas Borgström
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.8.2
Attachments: 2846.txt
Unless I've misunderstood the new way to do this with 0.8 I think update
keyspace is broken:
{code}
[default@unknown] create keyspace Test with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
[{replication_factor:1}];
37f70d40-a3e9-11e0--242d50cf1fbf
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] describe keyspace Test;
Keyspace: Test:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:1]
Column Families:
[default@unknown] update keyspace Test with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
[{replication_factor:2}];
489fe220-a3e9-11e0--242d50cf1fbf
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] describe keyspace Test;
Keyspace: Test:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:1]
Column Families:
{code}
Isn't the second describe keyspace supposed to to say
replication_factor:2?
Relevant bits from system.log:
{code}
Migration.java (line 116) Applying migration
489fe220-a3e9-11e0--242d50cf1fbf Update keyspace Testrep
strategy:SimpleStrategy{}durable_writes: true to Testrep
strategy:SimpleStrategy{}durable_writes: true
UpdateKeyspace.java (line 74) Keyspace updated. Please perform any manual
operations
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2837) Setting RR Chance via CliClient results in chance being too low
[
https://issues.apache.org/jira/browse/CASSANDRA-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes reassigned CASSANDRA-2837:
-
Assignee: Jon Hermes
Setting RR Chance via CliClient results in chance being too low
Key: CASSANDRA-2837
URL: https://issues.apache.org/jira/browse/CASSANDRA-2837
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.6
Reporter: Bill de hOra
Assignee: Jon Hermes
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2837) Setting RR Chance via CliClient results in chance being too low
[
https://issues.apache.org/jira/browse/CASSANDRA-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes updated CASSANDRA-2837:
--
Attachment: 2837.txt
Straightforward patch.
If the help says it expects a double from 0.0 to 1.0, it shouldn't then divide
by 100 as if expecting a percentage.
Setting RR Chance via CliClient results in chance being too low
Key: CASSANDRA-2837
URL: https://issues.apache.org/jira/browse/CASSANDRA-2837
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.6
Reporter: Bill de hOra
Fix For: 0.7.7
Attachments: 2837.txt
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040. Was expecting it to be 0.4.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2837) Setting RR Chance via CliClient results in chance being too low
[
https://issues.apache.org/jira/browse/CASSANDRA-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes reassigned CASSANDRA-2837:
-
Assignee: Jon Hermes
Setting RR Chance via CliClient results in chance being too low
Key: CASSANDRA-2837
URL: https://issues.apache.org/jira/browse/CASSANDRA-2837
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.6
Reporter: Bill de hOra
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.7
Attachments: 2837.txt
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040. Was expecting it to be 0.4.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2837) Setting RR Chance via CliClient results in chance being too low
[
https://issues.apache.org/jira/browse/CASSANDRA-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes updated CASSANDRA-2837:
--
Priority: Minor (was: Major)
Fix Version/s: 0.7.7
Setting RR Chance via CliClient results in chance being too low
Key: CASSANDRA-2837
URL: https://issues.apache.org/jira/browse/CASSANDRA-2837
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.6
Reporter: Bill de hOra
Priority: Minor
Fix For: 0.7.7
Attachments: 2837.txt
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040. Was expecting it to be 0.4.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2800) OPP#describeOwnership reports incorrect ownership
OPP#describeOwnership reports incorrect ownership
-
Key: CASSANDRA-2800
URL: https://issues.apache.org/jira/browse/CASSANDRA-2800
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.4
Reporter: Jon Hermes
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.7, 0.8.2
Attachments: 2800.txt
OPP#describeOwnership relies on StorageService#getSplits and counts the
received tokens as its basis of ownership.
When the number of result keys is less than the number of splits, the full
count is omitted (to save work?). However, we don't care if a split would end
up fractional in this case, we just need the full count.
The logic here is:
{code}
int splits = keycount * DatabaseDescriptor.getIndexInterval() / keysPerSplit;
if (keycount = splits) { ... add count to result set }
{code}
We were passing in 1 key per split (since we just care about the count), but
splits=keycount*IndexInterval is guaranteed to be keycount, so the result set
is not completely formed.
The better unit keysPerSplit to use is IndexInterval itself, which gives
splits=keycount*II/II=keycount, so the logic runs correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2800) OPP#describeOwnership reports incorrect ownership
[
https://issues.apache.org/jira/browse/CASSANDRA-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes updated CASSANDRA-2800:
--
Attachment: 2800.txt
OPP#describeOwnership reports incorrect ownership
-
Key: CASSANDRA-2800
URL: https://issues.apache.org/jira/browse/CASSANDRA-2800
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.4
Reporter: Jon Hermes
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.7, 0.8.2
Attachments: 2800.txt
OPP#describeOwnership relies on StorageService#getSplits and counts the
received tokens as its basis of ownership.
When the number of result keys is less than the number of splits, the full
count is omitted (to save work?). However, we don't care if a split would end
up fractional in this case, we just need the full count.
The logic here is:
{code}
int splits = keycount * DatabaseDescriptor.getIndexInterval() / keysPerSplit;
if (keycount = splits) { ... add count to result set }
{code}
We were passing in 1 key per split (since we just care about the count), but
splits=keycount*IndexInterval is guaranteed to be keycount, so the result
set is not completely formed.
The better unit keysPerSplit to use is IndexInterval itself, which gives
splits=keycount*II/II=keycount, so the logic runs correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2500: -- Attachment: rbcql-0.0.0.tgz v2. Attaching rbcql (CassDBD in DBI parlance). No longer takes the `old JDBC` approach of returning thrift objects, conforms to DBI return standards of array of values and a matching array of column_info containing type info and column names, the marshalling etc. is handled by DBI. Now also correctly tracks schema changes by REing queries as they come in (what pycql does). Should drop into a Rails system by including the package, changing the DBI-URLs to prefix with Cass, and making sure the input code is CQL, not SQL. Still not sure how best to require ruby c* bindings. (Looking at the cassandra-rubygem, they include the bindings in a vendor dir and keep them up to date.) Right now this expects interface/thrift/gen-rb/ to be in the same directory. 2622 problem is fixed by including key_alias info in the internal metadata (rubycql's copy of the schema). Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Reporter: Jon Hermes Assignee: Jon Hermes Attachments: 2500.txt, genthriftrb.txt, rbcql-0.0.0.tgz Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2500: -- Attachment: (was: rbcql-0.0.0.tgz) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Reporter: Jon Hermes Assignee: Jon Hermes Attachments: 2500.txt, genthriftrb.txt, rbcql-0.0.0.tgz Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2500: -- Attachment: rbcql-0.0.0.tgz Oops, left some comments in. Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Reporter: Jon Hermes Assignee: Jon Hermes Attachments: 2500.txt, genthriftrb.txt, rbcql-0.0.0.tgz Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2740) nodetool decommission should throw an error when there are extra params
[ https://issues.apache.org/jira/browse/CASSANDRA-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes reassigned CASSANDRA-2740: - Assignee: Jon Hermes nodetool decommission should throw an error when there are extra params --- Key: CASSANDRA-2740 URL: https://issues.apache.org/jira/browse/CASSANDRA-2740 Project: Cassandra Issue Type: Bug Components: Core Reporter: Brandon Williams Assignee: Jon Hermes Priority: Trivial Fix For: 0.7.7 removetoken takes a token parameter, but decommission works against the node where the call is issued. This allows confusion such as 'nodetool -h localhost decommission ip or token' actually decommissioning the local node, instead of whatever was passed to it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2740) nodetool decommission should throw an error when there are extra params
[ https://issues.apache.org/jira/browse/CASSANDRA-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2740: -- Attachment: 2740.txt All zero-arg commands now complain when there's extra args. nodetool decommission should throw an error when there are extra params --- Key: CASSANDRA-2740 URL: https://issues.apache.org/jira/browse/CASSANDRA-2740 Project: Cassandra Issue Type: Bug Components: Core Reporter: Brandon Williams Assignee: Jon Hermes Priority: Trivial Fix For: 0.7.7 Attachments: 2740.txt removetoken takes a token parameter, but decommission works against the node where the call is issued. This allows confusion such as 'nodetool -h localhost decommission ip or token' actually decommissioning the local node, instead of whatever was passed to it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13046015#comment-13046015 ] Jon Hermes commented on CASSANDRA-2500: --- The drivers should be tested functionally the same as the cli is currently. Ideally all the drivers, client libs, etc. should be hooked into a distributed testing framework, but for now it should be valid to just make sure it does the right thing on a single node system. Regarding packaging and mixing in with the ruby cassandra gem (in this case), I see good reasons to both combine the gems and to keep them seperate: In the latter case, it's as jbellis pointed out, we don't want to confuse people about which gem they need for a certain feature set (there's little overlap in the usage between this and the ruby cassandra gem). Also, it's possible to commit this to trunk, whereas client libs have historically been kept out of the repo. In the former, and from a dev perspective, there is a TON of reused code between the ruby cassandra gem and this driver, as there is likewise a TON of reused code between pycassa and the python cql driver. It would be nice to combine them/depend on them just for sanity purposes, and because it would force both gems/libs to be kept up to date and to be generally better. Overall I'd call it an executive call, and it appears one has already been made. Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Reporter: Jon Hermes Assignee: Jon Hermes Attachments: 2500.txt, genthriftrb.txt Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2713) Null strategy_options on a KsDef leads to an NPE.
Null strategy_options on a KsDef leads to an NPE. - Key: CASSANDRA-2713 URL: https://issues.apache.org/jira/browse/CASSANDRA-2713 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 beta 2 Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8.0 For add/update keyspace, a KsDef with null strategy_options will cause an NPE. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2713) Null strategy_options on a KsDef leads to an NPE.
[ https://issues.apache.org/jira/browse/CASSANDRA-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2713: -- Attachment: 2713-disallow.txt 2713-allow.txt Attaching two patches. `2713-allow` will allow nulls and default them to an empty set on KSMD creation. `2713-disallow` will explicitly block nulls during ThriftValidation. Both avoid NPEs and either are technically correct. Looks like we need to allow nulls because of upgrade issues coming from 0.7. Null strategy_options on a KsDef leads to an NPE. - Key: CASSANDRA-2713 URL: https://issues.apache.org/jira/browse/CASSANDRA-2713 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 beta 2 Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8.0 Attachments: 2713-allow.txt, 2713-disallow.txt For add/update keyspace, a KsDef with null strategy_options will cause an NPE. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2678) Incorrect NetworkTopolgyStrategy Options on upgrade from 0.7.5
[
https://issues.apache.org/jira/browse/CASSANDRA-2678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038011#comment-13038011
]
Jon Hermes commented on CASSANDRA-2678:
---
KSMetaData:55
{noformat}
maybeAddReplicationFactor(options, ks_def.strategy_class,
ks_def.isSetReplication_factor() ? ks_def.replication_factor : null);
{noformat}
...needs to be
{noformat}
maybeAddReplicationFactor(options, ks_def.strategy_class.toString(),
ks_def.replication_factor);
{noformat}
It's much clearer to not ternary on the value (since you're not going to use it
in the `ne SS || ONTS` case), and more importantly that ks_def.strategy_class
is a CharSequence, so you'll hit an error if you expect it to be a String in
maybe...().
Otherwise straightforward.
Incorrect NetworkTopolgyStrategy Options on upgrade from 0.7.5
--
Key: CASSANDRA-2678
URL: https://issues.apache.org/jira/browse/CASSANDRA-2678
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.0 beta 2
Environment: 10 node cluster, RHELL6.0
0.7.5, Single DC using NTS and RF=3 (DC1:3) - upgraded to 0.8.0-rc1.
Reporter: Chris Trahman
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.8.0
Attachments: 2678.txt
After an upgrade from 0.7.5 to 0.8.0-rc1 on a 10 node, single DC ring
configured with NTS, operations fail due to an inability to reach replicas in
the 'second datacenter':
ERROR [pool-2-thread-8] 2011-05-17 12:15:23,145 Cassandra.java (line 3294)
Internal error processing insert
java.lang.IllegalStateException: datacenter (replication_factor) has no more
endpoints, (3) replicas still needed
at
org.apache.cassandra.locator.NetworkTopologyStrategy.calculateNaturalEndpoints(NetworkTopologyStrategy.java:118)
at
org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:100)
at
org.apache.cassandra.service.StorageService.getNaturalEndpoints(StorageService.java:1611)
at
org.apache.cassandra.service.StorageService.getNaturalEndpoints(StorageService.java:1599)
at
org.apache.cassandra.service.StorageProxy.getWriteEndpoints(StorageProxy.java:217)
at
org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:202)
at
org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:154)
at
org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.java:557)
at
org.apache.cassandra.thrift.CassandraServer.internal_insert(CassandraServer.java:434)
at
org.apache.cassandra.thrift.CassandraServer.insert(CassandraServer.java:442)
at
org.apache.cassandra.thrift.Cassandra$Processor$insert.process(Cassandra.java:3286)
at
org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
DEBUG [ScheduledTasks:1] 2011-05-17 12:15:33,975 StorageLoadBalancer.java
(line 334) Disseminating load info ...
On checking the keyspace definition with cassandra-cli, it appears that
0.8.0-rc1 considered the 'replication_factor:3' configuration in the older
version as a DC name in part of the DC replication strategy:
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
Options: [replication_factor:3, DC1:3]
I attempted to remove replication_factor as a DC using the 'update keyspace'
command, but it would persist. I was able to remove the DC1:3 and use:
update keyspace MyKeyspace with strategy_options=[{replication_factor:3}];
then changed the topology properties file, renamed DC1 to replication_factor,
and it worked - so there is a workaround.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2678) Incorrect NetworkTopolgyStrategy Options on upgrade from 0.7.5
[
https://issues.apache.org/jira/browse/CASSANDRA-2678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038130#comment-13038130
]
Jon Hermes commented on CASSANDRA-2678:
---
bq. As above, it can't (since it is an int not an Integer), but it can be
unset.
I meant the null that we pass in line 55 because it was 'unset'.
I agree with the latter choice. We could doubly validate here and catch the
error just a _little_ bit faster than waiting for the class to validate, but
it's not a big deal. Assuming the duplicate code was removed, +1.
Incorrect NetworkTopolgyStrategy Options on upgrade from 0.7.5
--
Key: CASSANDRA-2678
URL: https://issues.apache.org/jira/browse/CASSANDRA-2678
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.0 beta 2
Environment: 10 node cluster, RHELL6.0
0.7.5, Single DC using NTS and RF=3 (DC1:3) - upgraded to 0.8.0-rc1.
Reporter: Chris Trahman
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.8.0
Attachments: 2678-v2.txt, 2678.txt
After an upgrade from 0.7.5 to 0.8.0-rc1 on a 10 node, single DC ring
configured with NTS, operations fail due to an inability to reach replicas in
the 'second datacenter':
ERROR [pool-2-thread-8] 2011-05-17 12:15:23,145 Cassandra.java (line 3294)
Internal error processing insert
java.lang.IllegalStateException: datacenter (replication_factor) has no more
endpoints, (3) replicas still needed
at
org.apache.cassandra.locator.NetworkTopologyStrategy.calculateNaturalEndpoints(NetworkTopologyStrategy.java:118)
at
org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:100)
at
org.apache.cassandra.service.StorageService.getNaturalEndpoints(StorageService.java:1611)
at
org.apache.cassandra.service.StorageService.getNaturalEndpoints(StorageService.java:1599)
at
org.apache.cassandra.service.StorageProxy.getWriteEndpoints(StorageProxy.java:217)
at
org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:202)
at
org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:154)
at
org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.java:557)
at
org.apache.cassandra.thrift.CassandraServer.internal_insert(CassandraServer.java:434)
at
org.apache.cassandra.thrift.CassandraServer.insert(CassandraServer.java:442)
at
org.apache.cassandra.thrift.Cassandra$Processor$insert.process(Cassandra.java:3286)
at
org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
DEBUG [ScheduledTasks:1] 2011-05-17 12:15:33,975 StorageLoadBalancer.java
(line 334) Disseminating load info ...
On checking the keyspace definition with cassandra-cli, it appears that
0.8.0-rc1 considered the 'replication_factor:3' configuration in the older
version as a DC name in part of the DC replication strategy:
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
Options: [replication_factor:3, DC1:3]
I attempted to remove replication_factor as a DC using the 'update keyspace'
command, but it would persist. I was able to remove the DC1:3 and use:
update keyspace MyKeyspace with strategy_options=[{replication_factor:3}];
then changed the topology properties file, renamed DC1 to replication_factor,
and it worked - so there is a workaround.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13034250#comment-13034250 ] Jon Hermes commented on CASSANDRA-2500: --- As a side note, this needs to be rolled into ruby-cassandra to avoid even more duplicate work. By the same token, pycassa and the py-cql driver need to be mashed up as well. Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Reporter: Jon Hermes Assignee: Jon Hermes Attachments: 2500.txt, genthriftrb.txt Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2500: -- Attachment: 2500.txt genthriftrb.txt genthriftrb just adds a gen-thrift-rb target to the build file. Not sure if it has general use, but I've written it 1 time now, so including. The patch adds drivers/rb/cass-dbd/*. It's heavily reliant on ruby DBI (0.4.3), so most of the hard work was abstracted out. That being said, it's still a rough fit because DBI expects SQL-systems. It's also Adapter compliant for use in RoR systems. Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Reporter: Jon Hermes Assignee: Jon Hermes Attachments: 2500.txt, genthriftrb.txt Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13034269#comment-13034269 ] Jon Hermes commented on CASSANDRA-2500: --- Ah, no. Hadn't seen that ticket yet. Rolling a v2 after some cogitation. Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Reporter: Jon Hermes Assignee: Jon Hermes Attachments: 2500.txt, genthriftrb.txt Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Reporter: Jon Hermes Assignee: Jon Hermes Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1969) Use BB for row cache - To Improve GC performance.
[ https://issues.apache.org/jira/browse/CASSANDRA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1969: -- Attachment: 1969-0001-v2.txt The test failure was due to CFMetaData:335. Also, 0001-introduce...txt didn't apply cleanly due to import rebasing. Both those changes are in 1969-0001-v2.txt (where the correct patch application is 0001-v2, then 0002...). Use BB for row cache - To Improve GC performance. - Key: CASSANDRA-1969 URL: https://issues.apache.org/jira/browse/CASSANDRA-1969 Project: Cassandra Issue Type: Improvement Components: Core Environment: Linux and Mac Reporter: Vijay Assignee: Vijay Priority: Minor Attachments: 0001-Config-1969.txt, 0001-introduce-ICache-InstrumentingCache-IRowCacheProvider.txt, 0001-introduce-ICache-InstrumentingCache-IRowCacheProvider.txt, 0002-Update_existing-1965.txt, 0002-implement-SerializingCache.txt, 0002-implement-SerializingCache.txt, 0002-implement-SerializingCacheV2.txt, 0003-New_Cache_Providers-1969.txt, 0003-add-ICache.isCopying-method.txt, 0004-Null-Check-and-duplicate-bb.txt, 0004-TestCase-1969.txt, 1969-0001-v2.txt, 1969-rollup-and-config.txt, 1969_Cache_SVN_Patch.diff, BB_Cache-1945.png, JMX-Cache-1945.png, Old_Cahce-1945.png, POC-0001-Config-1945.txt, POC-0002-Update_existing-1945.txt, POC-0003-New_Cache_Providers-1945.txt Java BB.allocateDirect() will allocate native memory out of the JVM and will help reducing the GC pressure in the JVM with a large Cache. From some of the basic tests it shows around 50% improvement than doing a normal Object cache. In addition this patch provide the users an option to choose BB.allocateDirect or store everything in the heap. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1263) Push replication factor down to the replication strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1263: -- Attachment: 1263-5.txt Updated schema-sample.txt. 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-2.txt, 1263-3.txt, 1263-4.txt, 1263-5.txt, 1263-incomplete.txt, 1263.txt Original Estimate: 8h Remaining Estimate: 8h 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2402) Python dbapi driver for CQL
Python dbapi driver for CQL --- Key: CASSANDRA-2402 URL: https://issues.apache.org/jira/browse/CASSANDRA-2402 Project: Cassandra Issue Type: Task Reporter: Jon Hermes Assignee: Jon Hermes Fix For: 0.8 Create a driver that emulates python's dbapi. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2311) type validated row keys
[
https://issues.apache.org/jira/browse/CASSANDRA-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012684#comment-13012684
]
Jon Hermes commented on CASSANDRA-2311:
---
I'm getting different test failures right now (the system tests are in a state
of flux), but the NPE definitely means the CFMetaData didn't get loaded
correctly or we're asking for it incorrectly.
As for moving vKT into vK, they have different args.
Assume key K validates correctly. K may validate correctly in CF Foo (because
the keyValidator is a no-op BytesType), but fail to validate in CF Bar (because
the keyValidator is something restrictive such as UTF8, and K is random bytes).
Ideally we'd like to just ask for the CFMD.keyValidator in every vK, but we
don't know that the CF they're asking for is valid either. We happen to have a
nice validateCF already, and it's a waste to duplicate work.
Hence why my original function was names validateKeyInCF... first you validate
the key on its own (it's nonzero bytes, etc.). Then you validate the cf (it's a
valid cf in the system). Lastly you validate that the key IN that cf is
altogether valid.
type validated row keys
---
Key: CASSANDRA-2311
URL: https://issues.apache.org/jira/browse/CASSANDRA-2311
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Eric Evans
Assignee: Jon Hermes
Labels: cql
Fix For: 0.8
Attachments: 2311.txt,
v1-0001-CASSANDRA-2311-missed-CFM-conversion.txt
The idea here is to allow the assignment of a column-family-wide key type
used to perform validation, (similar to how default_validation_class does for
column values).
This should be as straightforward as extending the column family schema to
include the new attribute, and updating {{ThriftValidation.validateKey}} to
validate the key ({{AbstractType.validate}}).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1263) Push replication factor down to the replication strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1263: -- Attachment: 1263-3.txt rebased. NOTE: system tests are currently failing. If the system tests in trunk runs fine and these continue to fail, please re-open. 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-2.txt, 1263-3.txt, 1263-incomplete.txt, 1263.txt Original Estimate: 8h Remaining Estimate: 8h 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2396) Allow key name metadata
[ https://issues.apache.org/jira/browse/CASSANDRA-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2396: -- Attachment: 2396.txt Patch adds the prop. If CLI support and/or JMX calls are needed to expose this even further, they can be added on this ticket. It would be nice to link the CQL dep. to this ticket in case something comes up. Allow key name metadata --- Key: CASSANDRA-2396 URL: https://issues.apache.org/jira/browse/CASSANDRA-2396 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jonathan Ellis Assignee: Jon Hermes Fix For: 0.8 Attachments: 2396.txt CASSANDRA-2311 allows typed keys. We also want to allow giving keys a name (that would need to conform to the CF comparator). This is required for Hive support; HIVE-1434 currently stores that metadata in an external repository but it would be cleaner to keep it in CFMetadata. This would allow CQL to support using the key name in select and where clauses, reducing the impedance mismatch between JDBC/CQL and JDBC/Hive. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2396) Allow key name metadata
[ https://issues.apache.org/jira/browse/CASSANDRA-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012266#comment-13012266 ] Jon Hermes commented on CASSANDRA-2396: --- Unrelated to this ticket but stumbled upon, moved convertToCFMD(thrift CfDef) into CFMD. It had no business being in CassandraServer. Allow key name metadata --- Key: CASSANDRA-2396 URL: https://issues.apache.org/jira/browse/CASSANDRA-2396 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jonathan Ellis Assignee: Jon Hermes Fix For: 0.8 Attachments: 2396.txt CASSANDRA-2311 allows typed keys. We also want to allow giving keys a name (that would need to conform to the CF comparator). This is required for Hive support; HIVE-1434 currently stores that metadata in an external repository but it would be cleaner to keep it in CFMetadata. This would allow CQL to support using the key name in select and where clauses, reducing the impedance mismatch between JDBC/CQL and JDBC/Hive. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2311) type validated row keys
[
https://issues.apache.org/jira/browse/CASSANDRA-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes updated CASSANDRA-2311:
--
Attachment: 2311.txt
ThriftValidation.validateKeyInColumnFamily(key, ksname, cfname) is the only
tricky part to this patch. I have to first validate the key is legit and the
column family is legit before I can scan the cf for the keyValidator to use to
validate the key.
Past that, it's just standard adding an option to CFMD and the required 10k of
code that comes with it.
In related news, check out http://wiki.apache.org/cassandra/ConfigurationNotes
for standard adding an option to CFMD notes.
type validated row keys
---
Key: CASSANDRA-2311
URL: https://issues.apache.org/jira/browse/CASSANDRA-2311
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Eric Evans
Assignee: Jon Hermes
Labels: cql
Fix For: 0.8
Attachments: 2311.txt
The idea here is to allow the assignment of a column-family-wide key type
used to perform validation, (similar to how default_validation_class does for
column values).
This should be as straightforward as extending the column family schema to
include the new attribute, and updating {{ThriftValidation.validateKey}} to
validate the key ({{AbstractType.validate}}).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1263) Push replication factor down to the replication strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1263: -- Attachment: 1263-2.txt Done and done. 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-2.txt, 1263-incomplete.txt, 1263.txt Original Estimate: 8h Remaining Estimate: 8h 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1263) Push replication factor down to the replication strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009805#comment-13009805 ] Jon Hermes commented on CASSANDRA-1263: --- There's a slight hiccup with avro filed at AVRO-786 . Inability to compare maps means that it's not possible to round-trip a KsDef test (in DatabaseDescriptorTest). Aside from that, patch posted. 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 Original Estimate: 8h Remaining Estimate: 8h 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1263) Push replication factor down to the replication strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1263: -- Attachment: 1263.txt 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, 1263.txt Original Estimate: 8h Remaining Estimate: 8h 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1263) Push replication factor down to the replication strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009811#comment-13009811 ] Jon Hermes commented on CASSANDRA-1263: --- Oh, not quite done. CLI still has bad help messages and it's not running through the code path that validates options on KSMD creation. 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, 1263.txt Original Estimate: 8h Remaining Estimate: 8h 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2351) Null CF comments should be allowed
[ https://issues.apache.org/jira/browse/CASSANDRA-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2351: -- Attachment: 2351.txt Enforces comment never null, also includes this test for further regression-catching. Null CF comments should be allowed -- Key: CASSANDRA-2351 URL: https://issues.apache.org/jira/browse/CASSANDRA-2351 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8 Reporter: Gary Dusbabek Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 2351.txt, null_cf_comment_test_case.patch Prior to 1906, cassandra tolerated null CF comments. They were converted to empty quotes when the CFM was created. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007510#comment-13007510 ] Jon Hermes commented on CASSANDRA-1906: --- Yes. If I only have to rebase this twice I'll consider it a miracle. Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 1906-2.txt, 1906.txt Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1906: -- Attachment: 1906-3.txt Rebased with new index changes. Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 1906-2.txt, 1906-3.txt, 1906.txt Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2345) CLI: Units on show keyspaces output
CLI: Units on show keyspaces output
---
Key: CASSANDRA-2345
URL: https://issues.apache.org/jira/browse/CASSANDRA-2345
Project: Cassandra
Issue Type: Improvement
Reporter: Jon Hermes
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 0.7.5, 0.8
Memtable thresholds don't give units/designations:
{code}
Memtable thresholds: 0.0375/8/60
{code}
By comparison, cache info fully qualifies the numbers.
{code}
Key cache size / save period: 0.01/14400
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1906: -- Attachment: 1906-4.txt Fixes all but one system test. Not done yet. Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 1906-2.txt, 1906-3.txt, 1906-4.txt, 1906.txt Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1906: -- Attachment: 1906-5.txt All tests passing. Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 1906-2.txt, 1906-3.txt, 1906-4.txt, 1906-5.txt, 1906.txt Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1906: -- Attachment: 1906-2.txt Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 1906-2.txt, 1906.txt Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1906: -- Attachment: (was: 1906-2.txt) Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 1906-2.txt, 1906.txt Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1761) Indexes: Auto-generating the CFname may collide with user-generated names
[
https://issues.apache.org/jira/browse/CASSANDRA-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes updated CASSANDRA-1761:
--
Attachment: 1761.txt
Indexes: Auto-generating the CFname may collide with user-generated names
-
Key: CASSANDRA-1761
URL: https://issues.apache.org/jira/browse/CASSANDRA-1761
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7 beta 3
Reporter: Jon Hermes
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.5
Attachments: 1761.txt
Original Estimate: 16h
Remaining Estimate: 16h
{noformat}column_families:
- name: CF
comparator: BytesType
column_metadata:
- name: foo
index_name: 626172
index_type: KEYS
- name: bar
index_type: KEYS{noformat}
Auto-generated versus user-supplied names collide in the YAML above. The code:
{code}cfname = parentCf + . + (info.getIndexName() == null ?
FBUtilities.bytesToHex(info.name) : info.getIndexName()){code}
From the first ColumnDefinition, we create cfname = CF.626172 (from the
fail clause of the ternany, user-supplied name)
From the second ColumnDefinition, we create cfname = CF.626172 (from the
pass clause of the ternary, we generate the name)
They're in hex form. This is possible, but fairly unlikely that someone will
do this.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1761) Indexes: Auto-generating the CFname may collide with user-generated names
[
https://issues.apache.org/jira/browse/CASSANDRA-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006729#comment-13006729
]
Jon Hermes commented on CASSANDRA-1761:
---
Because the column_metadata has to be passed in full, it can be fully validated
in ThriftValidation of the cf_def in the system_{update,add}_column_family and
system_add_keyspace calls.
In related news, I also found out that we never validated CfDefs in
system_update_column_family, so I'm surprised to say the least and glad it was
found in an innocuous bug instead of something more serious.
As for the one-schema-change-at-a-time rule, this is now enforced by default
with validateSchemaAgreement() calls in CassandraServer.
Indexes: Auto-generating the CFname may collide with user-generated names
-
Key: CASSANDRA-1761
URL: https://issues.apache.org/jira/browse/CASSANDRA-1761
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7 beta 3
Reporter: Jon Hermes
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.5
Attachments: 1761.txt
Original Estimate: 16h
Remaining Estimate: 16h
{noformat}column_families:
- name: CF
comparator: BytesType
column_metadata:
- name: foo
index_name: 626172
index_type: KEYS
- name: bar
index_type: KEYS{noformat}
Auto-generated versus user-supplied names collide in the YAML above. The code:
{code}cfname = parentCf + . + (info.getIndexName() == null ?
FBUtilities.bytesToHex(info.name) : info.getIndexName()){code}
From the first ColumnDefinition, we create cfname = CF.626172 (from the
fail clause of the ternany, user-supplied name)
From the second ColumnDefinition, we create cfname = CF.626172 (from the
pass clause of the ternary, we generate the name)
They're in hex form. This is possible, but fairly unlikely that someone will
do this.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1761) Indexes: Auto-generating the CFname may collide with user-generated names
[
https://issues.apache.org/jira/browse/CASSANDRA-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes updated CASSANDRA-1761:
--
Attachment: repro.cli
Also attaching repro script.
Without patch you should see an error trying to register an MBean twice, and
the first index will no longer work.
After patch you should see an IRE.
Indexes: Auto-generating the CFname may collide with user-generated names
-
Key: CASSANDRA-1761
URL: https://issues.apache.org/jira/browse/CASSANDRA-1761
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7 beta 3
Reporter: Jon Hermes
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.5
Attachments: 1761.txt, repro.cli
Original Estimate: 16h
Remaining Estimate: 16h
{noformat}column_families:
- name: CF
comparator: BytesType
column_metadata:
- name: foo
index_name: 626172
index_type: KEYS
- name: bar
index_type: KEYS{noformat}
Auto-generated versus user-supplied names collide in the YAML above. The code:
{code}cfname = parentCf + . + (info.getIndexName() == null ?
FBUtilities.bytesToHex(info.name) : info.getIndexName()){code}
From the first ColumnDefinition, we create cfname = CF.626172 (from the
fail clause of the ternany, user-supplied name)
From the second ColumnDefinition, we create cfname = CF.626172 (from the
pass clause of the ternary, we generate the name)
They're in hex form. This is possible, but fairly unlikely that someone will
do this.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1761) Indexes: Auto-generating the CFname may collide with user-generated names
[
https://issues.apache.org/jira/browse/CASSANDRA-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes updated CASSANDRA-1761:
--
Attachment: 1761-0.7.txt
1761.txt is for trunk.
1761-0.7.txt is for 0.7*.
(Slight difference in imports makes it not apply cleanly.)
Indexes: Auto-generating the CFname may collide with user-generated names
-
Key: CASSANDRA-1761
URL: https://issues.apache.org/jira/browse/CASSANDRA-1761
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7 beta 3
Reporter: Jon Hermes
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.5, 0.8
Attachments: 1761-0.7.txt, 1761.txt, repro.cli
Original Estimate: 16h
Remaining Estimate: 16h
{noformat}column_families:
- name: CF
comparator: BytesType
column_metadata:
- name: foo
index_name: 626172
index_type: KEYS
- name: bar
index_type: KEYS{noformat}
Auto-generated versus user-supplied names collide in the YAML above. The code:
{code}cfname = parentCf + . + (info.getIndexName() == null ?
FBUtilities.bytesToHex(info.name) : info.getIndexName()){code}
From the first ColumnDefinition, we create cfname = CF.626172 (from the
fail clause of the ternany, user-supplied name)
From the second ColumnDefinition, we create cfname = CF.626172 (from the
pass clause of the ternary, we generate the name)
They're in hex form. This is possible, but fairly unlikely that someone will
do this.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1906: -- Attachment: 1906.txt First two parts done, splintering the third part so the larger set can be in review while I experiment with some different designs on JMX re-ordering. Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 1906.txt Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2314) Reorder JMX heirarchy and expose all exposable tunables via JMX
Reorder JMX heirarchy and expose all exposable tunables via JMX
---
Key: CASSANDRA-2314
URL: https://issues.apache.org/jira/browse/CASSANDRA-2314
Project: Cassandra
Issue Type: Improvement
Reporter: Jon Hermes
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.8
For all per-node options:
- StorageService should have a JMX call to change any modifiable per-node
config option at runtime.
For all per-CF options:
- Each KSMD needs to sit on its respective Table
- Each CFMD needs to sit on its respective CFS (though SST{R,W} also needs to
be able to access the CFMD in a tight loop)
- As before, all modifiable config opts should have a matching JMX call in
Table/CFS
- Temporary changes are stronger than the schema and don't go away until reboot
or...
- an unsetOption() per-option should be available to revert any local config
changes.
Approx. MBean Hierarchy:
{noformat}
o.a.c.db (tree root)
/ || |\
SS CM HHOM CL KEYSPACES
/ (I/OM) / | \
ConfigK1K2...
| \ / \\\ ...
(D)EPS NodeOpts Table |\\_
/ / \ \
KSOpts/| ...
CF1 CF2
/ \ ...
CFS1 |
/CACHES
CFOpts | \
key row
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1906: -- Attachment: 1906-2.txt Whoops, included some files that got moved during the merge. patch-2 doesn't duplicate those moves (but it otherwise identical). Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 1906-2.txt, 1906.txt Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2221) 'show create' commands on the CLI to export schema
[ https://issues.apache.org/jira/browse/CASSANDRA-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005343#comment-13005343 ] Jon Hermes commented on CASSANDRA-2221: --- CASSANDRA-1906 completes the YAML removal (all that's left is with on-boot yaml load of per-node settings, which is fine as is). Tying this right next to the 'show keyspaces;' logic (maybe 'export keyspaces;') is going to be the easiest, as it already iterates through your settings. Instead of showing shorthand ( default_validation_class: BytesType), show longhand (with default_validation_class=BytesType ) and cascade them into a create column family ... output. 'show create' commands on the CLI to export schema -- Key: CASSANDRA-2221 URL: https://issues.apache.org/jira/browse/CASSANDRA-2221 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Jeremy Hanna Assignee: Aaron Morton Priority: Minor Labels: cli Fix For: 0.7.4 It would be nice to have 'show create' type of commands on the command-line so that it would generate the DDL for the schema. A scenario that would make this useful is where a team works out a data model over time with a dev cluster. They want to use parts of that schema for new clusters that they create, like a staging/prod cluster. It would be very handy in this scenario to have some sort of export mechanism. Another use case is for testing purposes - you want to replicate a problem. We currently have schematool for import/export but that is deprecated and it exports into yaml. This new feature would just be able to 'show' - or export if they want the entire keyspace - into a script or commands that could be used in a cli script. It would need to be able to regenerate everything about the keyspace including indexes and metadata. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1906) Sanitize configuration code
[
https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004304#comment-13004304
]
Jon Hermes commented on CASSANDRA-1906:
---
some notes:
CASSANDRA-2007 is the majority of the first part (drop deprecated yaml config).
Once that's completed, loadSchemaFromYaml() will be gutted,
RawKeyspace/ColumnFamily/ColumnDefinition and schematool removed. YAML is still
being used for the node config stuff, but there's much less magic there
(specifically the verbose snakeYAML descriptions of config relations). We don't
need schematool in trunk, but it will have to stay around in 0.7 for 0.6*
upgrades.
--
It doesn't look like Avro is leaving from the migration codepath, so CFMetaData
will likely still have to deal with both thrift and avro objects for now.
Builder pattern in CFMetaData helps gratuitously here to reduce code and
confusion, and DefsTest/DD/CFS will all have to use the new construction
pattern. There are two constructors: the standard one requires ks,name,type,and
comparators, and all other values defaulted, private one for system CFs that
set specific cfIDs, then a `CFMD foo(x) {foo=x;return this}` for each prop foo
to set it other than default.
Currently CFMD is mutable (and KSMD is not), so it doesn't specifically need to
use a builder class to produce CFMDs. They're currently mutable because they
are held in multiple places and there's a race condition when migrations come
in. This should be simplified (either immutable and held in one place, or
mutable with atomic references), but not for this ticket.
--
For all per-node options:
- Permanent changes are only made by changing the YAML.
- StorageService has all the JMX calls that change DD at runtime.
- To make a permanent change without restarting, change the yaml and make the
temp change. The next time it starts up, it's permanent.
- No thrift involved in node state.
For all per-CF options:
- Permanent changes must be made via migration. Thrift system_* calls, or the
cli wrappers for such.
- Each KSMD sits on its respective Table, each CFMD sits on its respective CFS.
SST{R,W} also needs to be able to access the CFMD in a tight loop.
Exposing Table (read: Keyspace) changes the MBean hierarchy, and some changes
should be made there as well to make it look more like the actual relations:
{noformat}
o.a.c.db (tree root)
/ || |\
SS CM HHOM CL KEYSPACES
/ (I/OM) / | \
ConfigK1 K2 ...
| \ / \ ...
(D)EPS NodeOpts Table |
/ ColumnFamilies
KSOpts/ | \
CF1 CF2 ...
/ \ ...
CFS1 |
/CACHES
CFOpts | \
key row
{noformat}
- Temporary changes are made via JMX (nodetool, Table/CFS beans). They are
stronger changes than new migrations coming in, so a temporary will persist
until the node reboots, regardless of new migrations. To use the settings set
in the most recent migration, either reboot the node or call unsetFoo() (next
to getFoo() and setFoo()) for a given property.
Sanitize configuration code
---
Key: CASSANDRA-1906
URL: https://issues.apache.org/jira/browse/CASSANDRA-1906
Project: Cassandra
Issue Type: Improvement
Reporter: Jon Hermes
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.8
Original Estimate: 24h
Remaining Estimate: 24h
Multipart:
- Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make
this gratuitously easy to do with sane defaults and accepting changesets as
opposed to full definitions.
- Combine common code between KS/CF/ColumnDefs and between thrift/avro defs.
- Provide an obvious and clean interface for changing settings locally versus
globally (JMX vs. thrift). Dox here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CASSANDRA-1906) Sanitize configuration code
[
https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004304#comment-13004304
]
Jon Hermes edited comment on CASSANDRA-1906 at 3/9/11 12:38 AM:
some notes:
CASSANDRA-2007 is the majority of the first part (drop deprecated yaml config).
Once that's completed, loadSchemaFromYaml() will be gutted,
RawKeyspace/ColumnFamily/ColumnDefinition and schematool removed. YAML is still
being used for the node config stuff, but there's much less magic there
(specifically the verbose snakeYAML descriptions of config relations). We don't
need schematool in trunk, but it will have to stay around in 0.7 for 0.6*
upgrades.
--
It doesn't look like Avro is leaving from the migration codepath, so CFMetaData
will likely still have to deal with both thrift and avro objects for now.
Builder pattern in CFMetaData helps gratuitously here to reduce code and
confusion, and DefsTest/DD/CFS will all have to use the new construction
pattern. There are two constructors: the standard one requires ks,name,type,and
comparators, and all other values defaulted, private one for system CFs that
set specific cfIDs, then a `CFMD foo( x ) {foo=x;return this}` for each prop
foo to set it other than default.
Currently CFMD is mutable (and KSMD is not), so it doesn't specifically need to
use a builder class to produce CFMDs. They're currently mutable because they
are held in multiple places and there's a race condition when migrations come
in. This should be simplified (either immutable and held in one place, or
mutable with atomic references), but not for this ticket.
--
For all per-node options:
- Permanent changes are only made by changing the YAML.
- StorageService has all the JMX calls that change DD at runtime.
- To make a permanent change without restarting, change the yaml and make the
temp change. The next time it starts up, it's permanent.
- No thrift involved in node state.
For all per-CF options:
- Permanent changes must be made via migration. Thrift system_* calls, or the
cli wrappers for such.
- Each KSMD sits on its respective Table, each CFMD sits on its respective CFS.
SST{R,W} also needs to be able to access the CFMD in a tight loop.
Exposing Table (read: Keyspace) changes the MBean hierarchy, and some changes
should be made there as well to make it look more like the actual relations:
{noformat}
o.a.c.db (tree root)
/ || |\
SS CM HHOM CL KEYSPACES
/ (I/OM) / | \
ConfigK1 K2 ...
| \ / \ ...
(D)EPS NodeOpts Table |
/ ColumnFamilies
KSOpts/ | \
CF1 CF2 ...
/ \ ...
CFS1 |
/CACHES
CFOpts | \
key row
{noformat}
- Temporary changes are made via JMX (nodetool, Table/CFS beans). They are
stronger changes than new migrations coming in, so a temporary will persist
until the node reboots, regardless of new migrations. To use the settings set
in the most recent migration, either reboot the node or call unsetFoo() (next
to getFoo() and setFoo()) for a given property.
was (Author: jhermes):
some notes:
CASSANDRA-2007 is the majority of the first part (drop deprecated yaml config).
Once that's completed, loadSchemaFromYaml() will be gutted,
RawKeyspace/ColumnFamily/ColumnDefinition and schematool removed. YAML is still
being used for the node config stuff, but there's much less magic there
(specifically the verbose snakeYAML descriptions of config relations). We don't
need schematool in trunk, but it will have to stay around in 0.7 for 0.6*
upgrades.
--
It doesn't look like Avro is leaving from the migration codepath, so CFMetaData
will likely still have to deal with both thrift and avro objects for now.
Builder pattern in CFMetaData helps gratuitously here to reduce code and
confusion, and DefsTest/DD/CFS will all have to use the new construction
pattern. There are two constructors: the standard one requires ks,name,type,and
comparators, and all other values defaulted, private one for system CFs that
set specific cfIDs, then a `CFMD foo(x) {foo=x;return this}` for each prop foo
to set it other than default.
Currently CFMD is mutable (and KSMD is not), so it doesn't specifically need to
use a builder class to produce CFMDs. They're currently mutable because they
are held in multiple places and there's a race condition when migrations come
in. This should be simplified (either immutable and held in one place, or
mutable with atomic references), but not for this ticket.
--
For all per-node options:
- Permanent changes are only made by changing the YAML.
- StorageService has all the JMX
[jira] Issue Comment Edited: (CASSANDRA-1906) Sanitize configuration code
[
https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004304#comment-13004304
]
Jon Hermes edited comment on CASSANDRA-1906 at 3/9/11 12:43 AM:
some notes:
CASSANDRA-2007 is the majority of the first part (drop deprecated yaml config).
Once that's completed, readTablesFromYaml() will be gutted,
RawKeyspace/ColumnFamily/ColumnDefinition and schematool removed. YAML is still
being used for the node config stuff, but there's much less magic there
(specifically the verbose snakeYAML descriptions of config relations). We don't
need schematool in trunk, but it will have to stay around in 0.7 for 0.6*
upgrades.
--
It doesn't look like Avro is leaving from the migration codepath, so CFMetaData
will likely still have to deal with both thrift and avro objects for now.
Builder pattern in CFMetaData helps gratuitously here to reduce code and
confusion, and DefsTest/DD/CFS will all have to use the new construction
pattern. There are two constructors: the standard one requires ks,name,type,and
comparators, and all other values defaulted, private one for system CFs that
set specific cfIDs, then a `CFMD foo( x ) {foo=x;return this}` for each prop
foo to set it other than default.
Currently CFMD is mutable (and KSMD is not), so it doesn't specifically need to
use a builder class to produce CFMDs. They're currently mutable because they
are held in multiple places and there's a race condition when migrations come
in. This should be simplified (either immutable and held in one place, or
mutable with atomic references), but not for this ticket.
--
For all per-node options:
- Permanent changes are only made by changing the YAML.
- StorageService has all the JMX calls that change DD at runtime.
- To make a permanent change without restarting, change the yaml and make the
temp change. The next time it starts up, it's permanent.
- No thrift involved in node state.
For all per-CF options:
- Permanent changes must be made via migration. Thrift system_* calls, or the
cli wrappers for such.
- Each KSMD sits on its respective Table, each CFMD sits on its respective CFS.
SST{R,W} also needs to be able to access the CFMD in a tight loop.
Exposing Table (read: Keyspace) changes the MBean hierarchy, and some changes
should be made there as well to make it look more like the actual relations:
{noformat}
o.a.c.db (tree root)
/ || |\
SS CM HHOM CL KEYSPACES
/ (I/OM) / | \
ConfigK1 K2 ...
| \ / \ ...
(D)EPS NodeOpts Table |
/ ColumnFamilies
KSOpts/ | \
CF1 CF2 ...
/ \ ...
CFS1 |
/CACHES
CFOpts | \
key row
{noformat}
- Temporary changes are made via JMX (nodetool, Table/CFS beans). They are
stronger changes than new migrations coming in, so a temporary will persist
until the node reboots, regardless of new migrations. To use the settings set
in the most recent migration, either reboot the node or call unsetFoo() (next
to getFoo() and setFoo()) for a given property.
was (Author: jhermes):
some notes:
CASSANDRA-2007 is the majority of the first part (drop deprecated yaml config).
Once that's completed, loadSchemaFromYaml() will be gutted,
RawKeyspace/ColumnFamily/ColumnDefinition and schematool removed. YAML is still
being used for the node config stuff, but there's much less magic there
(specifically the verbose snakeYAML descriptions of config relations). We don't
need schematool in trunk, but it will have to stay around in 0.7 for 0.6*
upgrades.
--
It doesn't look like Avro is leaving from the migration codepath, so CFMetaData
will likely still have to deal with both thrift and avro objects for now.
Builder pattern in CFMetaData helps gratuitously here to reduce code and
confusion, and DefsTest/DD/CFS will all have to use the new construction
pattern. There are two constructors: the standard one requires ks,name,type,and
comparators, and all other values defaulted, private one for system CFs that
set specific cfIDs, then a `CFMD foo( x ) {foo=x;return this}` for each prop
foo to set it other than default.
Currently CFMD is mutable (and KSMD is not), so it doesn't specifically need to
use a builder class to produce CFMDs. They're currently mutable because they
are held in multiple places and there's a race condition when migrations come
in. This should be simplified (either immutable and held in one place, or
mutable with atomic references), but not for this ticket.
--
For all per-node options:
- Permanent changes are only made by changing the YAML.
- StorageService has all the JMX
[jira] Commented: (CASSANDRA-2100) Restart required to change cache_save_period
[
https://issues.apache.org/jira/browse/CASSANDRA-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999489#comment-12999489
]
Jon Hermes commented on CASSANDRA-2100:
---
2100-2.txt works fine when the schema changes.
`if (!clientMode) { CFS.reload() }` will reset the config appropriately, and
it's good we don't do anything when clientMode because we don't apply() from
migration in that case as well (and there would be nothing to reset).
From your comment I thought that something didn't work. Don't scare me like
that. :P
Restart required to change cache_save_period
Key: CASSANDRA-2100
URL: https://issues.apache.org/jira/browse/CASSANDRA-2100
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0
Reporter: Nick Bailey
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.3
Attachments: 2100-2.txt, 2100-3.txt, 2100.txt
Original Estimate: 2h
Remaining Estimate: 2h
The cache_save_period is set in the schema for each column family. However
this value is only checked when a node starts up so changing this value isn't
really dynamic.
We should actually change this when the schema changes instead of having to
restart.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1969) Use BB for row cache - To Improve GC performance.
[ https://issues.apache.org/jira/browse/CASSANDRA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1969: -- Attachment: 1969-rollup-and-config.txt Adds row_cache_provider to CFMetaData. When it's coming in via YAML/thrift/avro, it's a string. It then creates an IRowCacheProvider in FBUtils like IPartitioner, et al. Doesn't handle changes at runtime, but a new ticket should be opened for that. Use BB for row cache - To Improve GC performance. - Key: CASSANDRA-1969 URL: https://issues.apache.org/jira/browse/CASSANDRA-1969 Project: Cassandra Issue Type: Improvement Components: Core Environment: Linux and Mac Reporter: Vijay Assignee: Vijay Priority: Minor Attachments: 0001-Config-1969.txt, 0001-introduce-ICache-InstrumentingCache-IRowCacheProvider.txt, 0002-Update_existing-1965.txt, 0002-implement-SerializingCache.txt, 0002-implement-SerializingCacheV2.txt, 0003-New_Cache_Providers-1969.txt, 0003-add-ICache.isCopying-method.txt, 0004-Null-Check-and-duplicate-bb.txt, 0004-TestCase-1969.txt, 1969-rollup-and-config.txt, BB_Cache-1945.png, JMX-Cache-1945.png, Old_Cahce-1945.png, POC-0001-Config-1945.txt, POC-0002-Update_existing-1945.txt, POC-0003-New_Cache_Providers-1945.txt Java BB.allocateDirect() will allocate native memory out of the JVM and will help reducing the GC pressure in the JVM with a large Cache. From some of the basic tests it shows around 50% improvement than doing a normal Object cache. In addition this patch provide the users an option to choose BB.allocateDirect or store everything in the heap. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2100) Restart required to change cache_save_period
[ https://issues.apache.org/jira/browse/CASSANDRA-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12998621#comment-12998621 ] Jon Hermes commented on CASSANDRA-2100: --- I thought that UpdateColumnFamily.applyModels() called CFS.reload() in all cases, but that only happens when the server is not in client mode. CFMetaData.apply(avro CfDef) will need to call the update logic. Patch forthcoming. Restart required to change cache_save_period Key: CASSANDRA-2100 URL: https://issues.apache.org/jira/browse/CASSANDRA-2100 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Nick Bailey Assignee: Jon Hermes Priority: Minor Fix For: 0.7.3 Attachments: 2100-2.txt, 2100.txt Original Estimate: 2h Remaining Estimate: 2h The cache_save_period is set in the schema for each column family. However this value is only checked when a node starts up so changing this value isn't really dynamic. We should actually change this when the schema changes instead of having to restart. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2100) Restart required to change cache_save_period
[ https://issues.apache.org/jira/browse/CASSANDRA-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2100: -- Attachment: 2100-3.txt Slight surprise in testing due to 2172 changes, but tests correctly (save period is updated at runtime for both JMX and schema migrations (both client and non-client mode)). Restart required to change cache_save_period Key: CASSANDRA-2100 URL: https://issues.apache.org/jira/browse/CASSANDRA-2100 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Nick Bailey Assignee: Jon Hermes Priority: Minor Fix For: 0.7.3 Attachments: 2100-2.txt, 2100-3.txt, 2100.txt Original Estimate: 2h Remaining Estimate: 2h The cache_save_period is set in the schema for each column family. However this value is only checked when a node starts up so changing this value isn't really dynamic. We should actually change this when the schema changes instead of having to restart. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2008) CLI help incorrect in places
[
https://issues.apache.org/jira/browse/CASSANDRA-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12998635#comment-12998635
]
Jon Hermes commented on CASSANDRA-2008:
---
bq. I am not a fan either of the cli somehow extracting yaml comments
Not what I was suggesting, but Aaron nailed it with the `commands: {name,help}`
blocks.
Hadn't seen #2007 yet, but that looks very good. Separating node.yaml and
schema.yaml is good, but separating and throwing away schema.yaml (for a script
solution) is even better.
I would rename `o.a.c.cli.CliHelp.yaml` to something more generic and move it
out of cli(conf/config_help.yaml). The cli can read it from there, it's an
intuitive place to find it for a new user, and it can be mirrored onto the wiki
and anywhere else it's referenced.
If there were a way to couple it with or generate it from
interface/cassandra.thrift:{Ks,Cf}Def, o.a.c.config.Raw{Keyspace,ColumnFamily}
and o.a.c.config.{KS,CF}MetaData, it would be even better-er. Currently all
three are kept in sync by force of will which has introduced multiple bugs
already. (Note: this is not in the scope of this ticket, but would be worth
keeping in mind.)
CLI help incorrect in places
Key: CASSANDRA-2008
URL: https://issues.apache.org/jira/browse/CASSANDRA-2008
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 0.7.0
Reporter: Aaron Morton
Assignee: Aaron Morton
Priority: Trivial
Fix For: 0.7.3
Found some errors in the CLI help, such as these for create column family.
- memtable_operations: Flush memtables after this many operations
- memtable_throughput: ... or after this many bytes have been written
- memtable_flush_after: ... or after this many seconds
Should be millions of ops, MB's written and minutes not seconds. Have
confirmed thats how the values are used. Will check all the help.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2100) Restart required to change cache_save_period
[ https://issues.apache.org/jira/browse/CASSANDRA-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2100: -- Attachment: 2100-2.txt Rebased. Restart required to change cache_save_period Key: CASSANDRA-2100 URL: https://issues.apache.org/jira/browse/CASSANDRA-2100 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Nick Bailey Assignee: Jon Hermes Priority: Minor Fix For: 0.7.3 Attachments: 2100-2.txt, 2100.txt Original Estimate: 2h Remaining Estimate: 2h The cache_save_period is set in the schema for each column family. However this value is only checked when a node starts up so changing this value isn't really dynamic. We should actually change this when the schema changes instead of having to restart. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2008) CLI help incorrect in places
[ https://issues.apache.org/jira/browse/CASSANDRA-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12995549#comment-12995549 ] Jon Hermes commented on CASSANDRA-2008: --- The problem is that it's yet another place to duplicate the config help. There should be one and only one definition of the config options and the sample config (conf/cassandra.yaml), the cli-help, and the wiki (and anything else that shows up) should all point to or read from that one definition like a bible. Adding more points of denormalization, while fine for c*, is bad for c* code. No matter how good the effort for this helpfile is, as new knobs and buttons get added to the config, it will suffer rot. Putting it in YAML wouldn't be my first choice as YAML is slowly getting deprecated, but that would suffice to make it parseable by the CLI and readable by the sample config at the same time. - Aside from the strategy for this bug, that help text looks pretty clean. I'd be sure to separate required from optional/defaulted (and give the defaults for these in a consistent way), and to sort the options. (The wiki sorts them alphabetically and groups them by related config, for example, and still not sure if that's ideal.) CLI help incorrect in places Key: CASSANDRA-2008 URL: https://issues.apache.org/jira/browse/CASSANDRA-2008 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 Reporter: Aaron Morton Assignee: Aaron Morton Priority: Trivial Fix For: 0.7.2 Found some errors in the CLI help, such as these for create column family. - memtable_operations: Flush memtables after this many operations - memtable_throughput: ... or after this many bytes have been written - memtable_flush_after: ... or after this many seconds Should be millions of ops, MB's written and minutes not seconds. Have confirmed thats how the values are used. Will check all the help. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12994565#comment-12994565 ] Jon Hermes commented on CASSANDRA-1906: --- +1, added to the list. Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993670#comment-12993670 ] Jon Hermes commented on CASSANDRA-1906: --- CFS has started to accumulate DefaultTs for settings that can be changed at runtime for per-node settings (min/max compaction threshold, and mem size/ops/time (soon row/key cache save period CASSANDRA-2100)). If we want to keep these ephemeral (non-migration) changes, then Tables (KSs) and StorageService (Global per-node settings) should follow in suit, and there should be one for every config option that doesn't impact the cluster (i.e. changing the saved_caches dir/ = Good, changing the partitioner or token ephemerally = bad). This reduces it to three paths: - Read from cassandra.yaml for SS settings at boot time, - Read from the schema and accept migrations to the schema for permanent KS/CF settings, - Change any per-node value at runtime in SS/Table/CFS, ... and the first and third may well be combined for a scant two _code_ paths (compare to current 4+ code paths) separated by the permanent/non-permanent taxonomy. Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993670#comment-12993670 ] Jon Hermes edited comment on CASSANDRA-1906 at 2/11/11 8:08 PM: CFS has started to accumulate DefaultTs for settings that can be changed at runtime for per-node settings (min/max compaction threshold, and mem size/ops/time (soon row/key cache save period CASSANDRA-2100)). If we want to keep these ephemeral (non-migration) changes, then Tables (KSs) and StorageService (Global per-node settings) should follow in suit, and there should be one for every config option that doesn't impact the cluster (i.e. changing the max_hint_window ephemerally = Good, changing the partitioner or token ephemerally = Bad/impossible). This reduces it to three paths: - Read from cassandra.yaml for SS settings at boot time, - Read from the schema and accept migrations to the schema for permanent KS/CF settings, - Change any per-node value at runtime in SS/Table/CFS, ... and the first and third may well be combined for a scant two _code_ paths (compare to current 4+ code paths) separated by the permanent/non-permanent taxonomy. was (Author: jhermes): CFS has started to accumulate DefaultTs for settings that can be changed at runtime for per-node settings (min/max compaction threshold, and mem size/ops/time (soon row/key cache save period CASSANDRA-2100)). If we want to keep these ephemeral (non-migration) changes, then Tables (KSs) and StorageService (Global per-node settings) should follow in suit, and there should be one for every config option that doesn't impact the cluster (i.e. changing the saved_caches dir/ = Good, changing the partitioner or token ephemerally = bad). This reduces it to three paths: - Read from cassandra.yaml for SS settings at boot time, - Read from the schema and accept migrations to the schema for permanent KS/CF settings, - Change any per-node value at runtime in SS/Table/CFS, ... and the first and third may well be combined for a scant two _code_ paths (compare to current 4+ code paths) separated by the permanent/non-permanent taxonomy. Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2100) Restart required to change cache_save_period
[ https://issues.apache.org/jira/browse/CASSANDRA-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2100: -- Attachment: 2100.txt row/key cache save period in seconds now config-able at runtime via JMX (not just migrations). On either migration or JMX-change path, the scheduling has been broken out. It first cancels the previous scheduled task (but will not interrupt currently saving caches) then schedules a new task with the correct frequency. Restart required to change cache_save_period Key: CASSANDRA-2100 URL: https://issues.apache.org/jira/browse/CASSANDRA-2100 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Nick Bailey Assignee: Jon Hermes Priority: Minor Fix For: 0.7.2 Attachments: 2100.txt The cache_save_period is set in the schema for each column family. However this value is only checked when a node starts up so changing this value isn't really dynamic. We should actually change this when the schema changes instead of having to restart. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (CASSANDRA-2100) Restart required to change cache_save_period
[ https://issues.apache.org/jira/browse/CASSANDRA-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes reassigned CASSANDRA-2100: - Assignee: Matthew F. Dennis (was: Jon Hermes) Restart required to change cache_save_period Key: CASSANDRA-2100 URL: https://issues.apache.org/jira/browse/CASSANDRA-2100 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Nick Bailey Assignee: Matthew F. Dennis Priority: Minor Fix For: 0.7.2 The cache_save_period is set in the schema for each column family. However this value is only checked when a node starts up so changing this value isn't really dynamic. We should actually change this when the schema changes instead of having to restart. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1551) create tell me what nodes you have hints for jmx api
[ https://issues.apache.org/jira/browse/CASSANDRA-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1551: -- Attachment: 1551-v4.txt Rebased, deleteHFE() now accepts an ipaddr or hostname. create tell me what nodes you have hints for jmx api -- Key: CASSANDRA-1551 URL: https://issues.apache.org/jira/browse/CASSANDRA-1551 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Jon Hermes Priority: Minor Fix For: 0.7.2 Attachments: 1551-v2.txt, 1551-v3.txt, 1551-v4.txt, 1551.txt Original Estimate: 4h Remaining Estimate: 4h we can do this efficiently in 0.7 due to new HH schema. in 0.6 this would require scanning all hints so probably not worth it. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2008) CLI help incorrect in places
[ https://issues.apache.org/jira/browse/CASSANDRA-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987704#action_12987704 ] Jon Hermes commented on CASSANDRA-2008: --- The YAML should be correct, and http://wiki.apache.org/cassandra/StorageConfiguration should be ultimately correct. All should say the same things. CLI help incorrect in places Key: CASSANDRA-2008 URL: https://issues.apache.org/jira/browse/CASSANDRA-2008 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 Reporter: Aaron Morton Assignee: Aaron Morton Priority: Trivial Fix For: 0.7.2 Found some errors in the CLI help, such as these for create column family. - memtable_operations: Flush memtables after this many operations - memtable_throughput: ... or after this many bytes have been written - memtable_flush_after: ... or after this many seconds Should be millions of ops, MB's written and minutes not seconds. Have confirmed thats how the values are used. Will check all the help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2071) RP.describeOwnership() does some bad math
RP.describeOwnership() does some bad math - Key: CASSANDRA-2071 URL: https://issues.apache.org/jira/browse/CASSANDRA-2071 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor If the input isn't sorted correctly for some reason, then describeOwnership() fails to calculate the ownership %ages correctly. Repro is 2 nodes with these tokens, you get these fractions: 49000620740128447720217646403197156812 : 0.7615167 770141183460469231731687303715884105727 : 4.2384834 423% ownership is obviously broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2071) RP.describeOwnership() does some bad math
[ https://issues.apache.org/jira/browse/CASSANDRA-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2071: -- Attachment: 2071.txt Fixes the math by using a closed form in all cases. Now returns: 49000620740128447720217646403197156812 : 0.7615167 770141183460469231731687303715884105727 : 0.2384833 RP.describeOwnership() does some bad math - Key: CASSANDRA-2071 URL: https://issues.apache.org/jira/browse/CASSANDRA-2071 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Attachments: 2071.txt If the input isn't sorted correctly for some reason, then describeOwnership() fails to calculate the ownership %ages correctly. Repro is 2 nodes with these tokens, you get these fractions: 49000620740128447720217646403197156812 : 0.7615167 770141183460469231731687303715884105727 : 4.2384834 423% ownership is obviously broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2071) RP.describeOwnership() does some bad math
[ https://issues.apache.org/jira/browse/CASSANDRA-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2071: -- Attachment: (was: 2071.txt) RP.describeOwnership() does some bad math - Key: CASSANDRA-2071 URL: https://issues.apache.org/jira/browse/CASSANDRA-2071 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Attachments: 2071.txt If the input isn't sorted correctly for some reason, then describeOwnership() fails to calculate the ownership %ages correctly. Repro is 2 nodes with these tokens, you get these fractions: 49000620740128447720217646403197156812 : 0.7615167 770141183460469231731687303715884105727 : 4.2384834 423% ownership is obviously broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2071) RP.describeOwnership() does some bad math
[ https://issues.apache.org/jira/browse/CASSANDRA-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2071: -- Attachment: 2071.txt Whoops, wrong file. RP.describeOwnership() does some bad math - Key: CASSANDRA-2071 URL: https://issues.apache.org/jira/browse/CASSANDRA-2071 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Attachments: 2071.txt If the input isn't sorted correctly for some reason, then describeOwnership() fails to calculate the ownership %ages correctly. Repro is 2 nodes with these tokens, you get these fractions: 49000620740128447720217646403197156812 : 0.7615167 770141183460469231731687303715884105727 : 4.2384834 423% ownership is obviously broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1551) create tell me what nodes you have hints for jmx api
[ https://issues.apache.org/jira/browse/CASSANDRA-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12986801#action_12986801 ] Jon Hermes commented on CASSANDRA-1551: --- The original deleteHintsForEndpoint(InetAddr) that is called by StorageService#excise and eventually from removetoken/decommission is broken. It doesn't actually delete the hints row because it munges the key. create tell me what nodes you have hints for jmx api -- Key: CASSANDRA-1551 URL: https://issues.apache.org/jira/browse/CASSANDRA-1551 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Jon Hermes Priority: Minor Fix For: 0.7.2 Attachments: 1551-v2.txt, 1551.txt Original Estimate: 4h Remaining Estimate: 4h we can do this efficiently in 0.7 due to new HH schema. in 0.6 this would require scanning all hints so probably not worth it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1551) create tell me what nodes you have hints for jmx api
[ https://issues.apache.org/jira/browse/CASSANDRA-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1551: -- Attachment: 1551-v2.txt Rebased, matches import code style. create tell me what nodes you have hints for jmx api -- Key: CASSANDRA-1551 URL: https://issues.apache.org/jira/browse/CASSANDRA-1551 Project: Cassandra Issue Type: New Feature Components: Tools Affects Versions: 0.7.0 Reporter: Jonathan Ellis Assignee: Jon Hermes Priority: Minor Fix For: 0.7.1 Attachments: 1551-v2.txt, 1551.txt Original Estimate: 4h Remaining Estimate: 4h we can do this efficiently in 0.7 due to new HH schema. in 0.6 this would require scanning all hints so probably not worth it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12981978#action_12981978 ] Jon Hermes commented on CASSANDRA-1906: --- - Dropping avro (CASSANDRA-926) makes the [KS,CF,Column]Def changes much easier. I know at least CfDef will be cut in half. - If not dropping YAML entirely, then at least cleaning up the code around it and making a serious effort to use YAMLBeans (previous reverted yaml lib changes (CASSANDRA-1313) removed 100 lines of code, and YAMLBeans itself is ~10% the mass of snakeYAML) should be done. The differences between the libraries are now known. - Taking a census of all the settings knobs and sorting them into JMX vs. Thrift needs to be done to make the separation consistent, or if this isn't done, then we should have all methods available on both Thrift and JMX. In either case, the reasoning is that future methods won't have to endure an argument as to their placement; i.e. either it obviously goes in one, or necessarily goes in both. The core tenet of this improvement/ticket is making the code easier for future maintenance; the more unnecessary lines removed and the more commentary and documentation available the better. There's currently a *ton* of redundant code and deprecated flags running around in DD, the Defs, and SS, and missing a single spot of redundancy means an unusable feature (CASSANDRA-1606, CASSANDRA-1466). Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1551) create tell me what nodes you have hints for jmx api
[ https://issues.apache.org/jira/browse/CASSANDRA-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1551: -- Attachment: 1551.txt HHOM is now exposed via HHOM-MBean. The MBean is registered during first construction, which is made during SS.initServer(). The MBean has three methods: deleteHintsForEndpoint, listEndpointsPendingHints, and the supermethod, countPendingHints. create tell me what nodes you have hints for jmx api -- Key: CASSANDRA-1551 URL: https://issues.apache.org/jira/browse/CASSANDRA-1551 Project: Cassandra Issue Type: New Feature Components: Tools Affects Versions: 0.7.0 Reporter: Jonathan Ellis Assignee: Jon Hermes Priority: Minor Fix For: 0.7.1 Attachments: 1551.txt Original Estimate: 4h Remaining Estimate: 4h we can do this efficiently in 0.7 due to new HH schema. in 0.6 this would require scanning all hints so probably not worth it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1551) create tell me what nodes you have hints for jmx api
[ https://issues.apache.org/jira/browse/CASSANDRA-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1551: -- Attachment: (was: 1551-nuke.txt) create tell me what nodes you have hints for jmx api -- Key: CASSANDRA-1551 URL: https://issues.apache.org/jira/browse/CASSANDRA-1551 Project: Cassandra Issue Type: New Feature Components: Tools Affects Versions: 0.7.0 Reporter: Jonathan Ellis Assignee: Jon Hermes Priority: Minor Fix For: 0.7.1 Attachments: 1551.txt Original Estimate: 4h Remaining Estimate: 4h we can do this efficiently in 0.7 due to new HH schema. in 0.6 this would require scanning all hints so probably not worth it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1857) nodetool has invalidaterowcache but no invalidatekeycache
[ https://issues.apache.org/jira/browse/CASSANDRA-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1857: -- Attachment: 1857.txt Add invalidateKeyCache, add both to NodeCmd (with all the spiffy optional KS and CFs ala repair/compact/cleanup/flush). nodetool has invalidaterowcache but no invalidatekeycache - Key: CASSANDRA-1857 URL: https://issues.apache.org/jira/browse/CASSANDRA-1857 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Robert Coli Assignee: Jon Hermes Priority: Trivial Attachments: 1857.txt In many cases where you would want to use invalidaterowcache, you would probably also want to invalidatekeycache. Currently, you can invalidaterowcache, but not invalidatekeycache. It seems that users should, generally, be able to do both or neither, but not one or the other. A brief look at the NodeCmd/ColumnFamilyStore code suggests that the stubs/hooks for this feature do not currently exist. =Rob -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1857) nodetool has invalidaterowcache but no invalidatekeycache
[ https://issues.apache.org/jira/browse/CASSANDRA-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1857: -- Fix Version/s: 0.7.1 nodetool has invalidaterowcache but no invalidatekeycache - Key: CASSANDRA-1857 URL: https://issues.apache.org/jira/browse/CASSANDRA-1857 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Robert Coli Assignee: Jon Hermes Priority: Trivial Fix For: 0.7.1 Attachments: 1857.txt In many cases where you would want to use invalidaterowcache, you would probably also want to invalidatekeycache. Currently, you can invalidaterowcache, but not invalidatekeycache. It seems that users should, generally, be able to do both or neither, but not one or the other. A brief look at the NodeCmd/ColumnFamilyStore code suggests that the stubs/hooks for this feature do not currently exist. =Rob -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1551) create tell me what nodes you have hints for jmx api
[ https://issues.apache.org/jira/browse/CASSANDRA-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1551: -- Attachment: 1551-nuke.txt bq. ability to nuke hints for a given node would also be useful. HHOM already has a nukeHintsFor(InetAddr), so the attached nuke patch exposes it via SS (and takes a string, which is a little nicer). create tell me what nodes you have hints for jmx api -- Key: CASSANDRA-1551 URL: https://issues.apache.org/jira/browse/CASSANDRA-1551 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Jon Hermes Priority: Minor Fix For: 0.7.1 Attachments: 1551-nuke.txt we can do this efficiently in 0.7 due to new HH schema. in 0.6 this would require scanning all hints so probably not worth it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1374) Make snitches configurable at runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1374: -- Attachment: 1374-v4.txt DES registers itself during construction. Explicit call to ((DES)eps).unregisterMBean() added. Braces on newlines removed. Make snitches configurable at runtime - Key: CASSANDRA-1374 URL: https://issues.apache.org/jira/browse/CASSANDRA-1374 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 rc 1 Reporter: Jeremy Hanna Assignee: Jon Hermes Fix For: 0.7.1 Attachments: 1374-2.txt, 1374-rebase.txt, 1374-v4.txt, 1374.txt There needs to be the capability to configure snitches at runtime, even though there is now a dynamic endpoint snitch - CASSANDRA-981. -- 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-1374) Make snitches configurable at runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12975675#action_12975675 ] Jon Hermes edited comment on CASSANDRA-1374 at 12/28/10 6:16 PM: - DES registers itself during construction. Explicit call to ((DES)eps).unregisterMBean() added. Braces not on newlines removed, then added immediately afterward (on a newline, no less). was (Author: jhermes): DES registers itself during construction. Explicit call to ((DES)eps).unregisterMBean() added. Braces on newlines removed. Make snitches configurable at runtime - Key: CASSANDRA-1374 URL: https://issues.apache.org/jira/browse/CASSANDRA-1374 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 rc 1 Reporter: Jeremy Hanna Assignee: Jon Hermes Fix For: 0.7.1 Attachments: 1374-2.txt, 1374-rebase.txt, 1374-v4.txt, 1374.txt There needs to be the capability to configure snitches at runtime, even though there is now a dynamic endpoint snitch - CASSANDRA-981. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1374) Make snitches configurable at runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1374: -- Attachment: 1374-rebase.txt Just needed to shift the MBean abs. method down a line. Silly diff. Make snitches configurable at runtime - Key: CASSANDRA-1374 URL: https://issues.apache.org/jira/browse/CASSANDRA-1374 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 rc 1 Reporter: Jeremy Hanna Assignee: Jon Hermes Fix For: 0.7.1 Attachments: 1374-2.txt, 1374-rebase.txt, 1374.txt There needs to be the capability to configure snitches at runtime, even though there is now a dynamic endpoint snitch - CASSANDRA-981. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1857) nodetool has invalidaterowcache but no invalidatekeycache
[ https://issues.apache.org/jira/browse/CASSANDRA-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971847#action_12971847 ] Jon Hermes commented on CASSANDRA-1857: --- Just to be clear, nodetool doesn't have this, but there is a JMX call on ColumnFamilyStores to invalidateRowCache() (due to CASSANDRA-761). nodetool has invalidaterowcache but no invalidatekeycache - Key: CASSANDRA-1857 URL: https://issues.apache.org/jira/browse/CASSANDRA-1857 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Robert Coli Assignee: Jon Hermes Priority: Trivial In many cases where you would want to use invalidaterowcache, you would probably also want to invalidatekeycache. Currently, you can invalidaterowcache, but not invalidatekeycache. It seems that users should, generally, be able to do both or neither, but not one or the other. A brief look at the NodeCmd/ColumnFamilyStore code suggests that the stubs/hooks for this feature do not currently exist. =Rob -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1843) Indexes: CF MBeans for automatic indexes are never unregistered when they are deleted.
Indexes: CF MBeans for automatic indexes are never unregistered when they are
deleted.
--
Key: CASSANDRA-1843
URL: https://issues.apache.org/jira/browse/CASSANDRA-1843
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.0 rc 1
Reporter: Jon Hermes
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.0 rc 2
Add, delete, and add the same index and you should get a stacktrace to this
effect:
{noformat}
java.lang.RuntimeException: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=IndexColumnFamilies,keyspace=Keyspace1,columnfamily=Standard1.616765
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:259)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:447)
at
org.apache.cassandra.db.ColumnFamilyStore.addIndex(ColumnFamilyStore.java:304)
at
org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:193)
at
org.apache.cassandra.db.migration.UpdateColumnFamily.applyModels(UpdateColumnFamily.java:80)
at org.apache.cassandra.db.migration.Migration.apply(Migration.java:171)
at
org.apache.cassandra.thrift.CassandraServer$2.call(CassandraServer.java:663)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=IndexColumnFamilies,keyspace=Keyspace1,columnfamily=Standard1.616765
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:255)
... 11 more{noformat}
CFS.reload() manages index deletion, but never unregisters the MBeans it
creates during initialization.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1812: -- Attachment: 1812-4.txt Rebased. Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.6.8 Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9, 0.7.0 Attachments: 1812-2.txt, 1812-3.txt, 1812-4.txt, 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1812: -- Attachment: 1812-2.txt This code is now DIAMONDS. :: per-CF compaction and cleanup added. :: Massive cleanup of NodeCmd code. :: flush and repair now operate without being given a keyspace (i.e. all keyspaces will be flushed/repaired). More specifically, flush|repair|compact|cleanup all run through the same code-path. Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.6.8 Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9, 0.7.0 Attachments: 1812-2.txt, 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1812: -- Attachment: (was: 1812-2.txt) Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.6.8 Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9, 0.7.0 Attachments: 1812-2.txt, 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1812: -- Attachment: 1812-2.txt Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.6.8 Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9, 0.7.0 Attachments: 1812-2.txt, 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1812: -- Attachment: 1812-3.txt I need to better enforce that the system keyspace should not be cleaned up. Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.6.8 Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9, 0.7.0 Attachments: 1812-2.txt, 1812-3.txt, 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1812: -- Attachment: 1812-compact.txt Compaction per-CF. Either poke StorageService MBean (forceTableCompaction with two args, ks and cf names), or run `nodetool -h HOST compact KEYSPACE CFNAME`. Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9 Attachments: 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966659#action_12966659 ] Jon Hermes commented on CASSANDRA-1812: --- Repair already is per-CF, but is apparently undocumented. Either poke StorageService MBean (forceTableRepair with N+1 args, where the first arg is ks and any number of CF names within that ks following), or run `nodetool -h HOST repair KEYSPACE CF1 CF2 CF3...`. (And with that, I'm changing the compaction patch to follow this style.) Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9 Attachments: 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1812: -- Attachment: 1812-compact-2.txt Compaction takes N cfnames in the same style as repair. Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9 Attachments: 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1812: -- Attachment: 1812-all.txt Both compaction and cleanup run through roughly the same code path. It's very similar to repair, but allows for compact/cleanup with no args - run on every ks/cf, whereas repair requires a keyspace. Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.6.8 Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9 Attachments: 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966686#action_12966686 ] Jon Hermes commented on CASSANDRA-1812: --- Note: I'd love to port this to 0.7/trunk and clean up all the junky logic. There are a LOT of similarities between a LOT of commands, so a LOT of duplicate code can be removed. I'm not making the 0.6 version extra pretty, but it would be nice to do so for the current builds. Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.6.8 Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9 Attachments: 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1811) Cleanup smallest CFs first
[ https://issues.apache.org/jira/browse/CASSANDRA-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966706#action_12966706 ] Jon Hermes commented on CASSANDRA-1811: --- bq. An alternative would be to extend forceclean in jmx to allow you to specify both the Keyspace and a CF, so that you could manually do specific CFs. This is resolved in CASSANDRA-1812, but there's value in both. Cleanup smallest CFs first -- Key: CASSANDRA-1811 URL: https://issues.apache.org/jira/browse/CASSANDRA-1811 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Paul Querna Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9 When running a cleanup, it would be an advantage to anti-compact the smallest SSTables first, so that free disk space is gradually increased, so that larger sstables later on are more likely to successfully anti-compact. In 0.6, currently Table.forceCleanup() just iterates the list of CFs in whatever order they come from tableMetadata.getColumnFamilies, which is just a keySet(). The code should be changed to sort the CFs, smallest first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966719#action_12966719
]
Jon Hermes commented on CASSANDRA-1812:
---
No, it handles that logic (in the exact same way repair does).
{code}
column_families.length == 0 ? working_set = all : working_set = column_families
{code}
... at the top of the command().
Allow per-CF compaction, repair, and cleanup
Key: CASSANDRA-1812
URL: https://issues.apache.org/jira/browse/CASSANDRA-1812
Project: Cassandra
Issue Type: New Feature
Components: Core
Affects Versions: 0.6.8
Reporter: Tyler Hobbs
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.6.9
Attachments: 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt
It should be a pretty simple change to allow compaction, cleanup, or repair
of only one CF.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1811) Cleanup smallest CFs first
[ https://issues.apache.org/jira/browse/CASSANDRA-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1811: -- Attachment: 1811.txt This may need to be rebased if 1812 is committed first and vice-versa. Oh well. Cleanup smallest CFs first -- Key: CASSANDRA-1811 URL: https://issues.apache.org/jira/browse/CASSANDRA-1811 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.6.8 Reporter: Paul Querna Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9 Attachments: 1811.txt When running a cleanup, it would be an advantage to anti-compact the smallest SSTables first, so that free disk space is gradually increased, so that larger sstables later on are more likely to successfully anti-compact. In 0.6, currently Table.forceCleanup() just iterates the list of CFs in whatever order they come from tableMetadata.getColumnFamilies, which is just a keySet(). The code should be changed to sort the CFs, smallest first. -- 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-1811) Cleanup smallest CFs first
[ https://issues.apache.org/jira/browse/CASSANDRA-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966751#action_12966751 ] Jon Hermes edited comment on CASSANDRA-1811 at 12/3/10 7:56 PM: -This may need to be rebased if 1812 is committed first and vice-versa.- -Oh well.- Nope, both apply cleanly. Hurrah! was (Author: jhermes): This may need to be rebased if 1812 is committed first and vice-versa. Oh well. Cleanup smallest CFs first -- Key: CASSANDRA-1811 URL: https://issues.apache.org/jira/browse/CASSANDRA-1811 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.6.8 Reporter: Paul Querna Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9 Attachments: 1811.txt When running a cleanup, it would be an advantage to anti-compact the smallest SSTables first, so that free disk space is gradually increased, so that larger sstables later on are more likely to successfully anti-compact. In 0.6, currently Table.forceCleanup() just iterates the list of CFs in whatever order they come from tableMetadata.getColumnFamilies, which is just a keySet(). The code should be changed to sort the CFs, smallest first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1801) memory leak under heavy write load
[ https://issues.apache.org/jira/browse/CASSANDRA-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965869#action_12965869 ] Jon Hermes commented on CASSANDRA-1801: --- CASSANDRA-1014 cause? memory leak under heavy write load -- Key: CASSANDRA-1801 URL: https://issues.apache.org/jira/browse/CASSANDRA-1801 Project: Cassandra Issue Type: Bug Affects Versions: 0.7 beta 3 Reporter: Matthew F. Dennis Assignee: T Jake Luciani Fix For: 0.7.0 Attachments: screenie.png It appears C* isn't releasing buffers that were used during the writes of batch mutates. See attached screenshot of heap dump. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
