[jira] [Commented] (CASSANDRA-4377) CQL3 column value validation bug
[ https://issues.apache.org/jira/browse/CASSANDRA-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411298#comment-13411298 ] Sylvain Lebresne commented on CASSANDRA-4377: - bq. are we just talking about not supporting Thrift addressing columns inside composites by their CQL3 names That is not what I was talking about, but I don't even understand how we could ever support that. bq. disabling Thrift access entirely to columnfamilies which use named metadata with composites That is what I'm talking about (though to be precise, it would be for composites using named metadata *created through CQL3*). Anyway, I don't know if that's so crazy but in any case calling it crazy doesn't help solving the problem. CQL3 column value validation bug Key: CASSANDRA-4377 URL: https://issues.apache.org/jira/browse/CASSANDRA-4377 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.1 Reporter: Nick Bailey Assignee: Sylvain Lebresne Fix For: 1.1.3 Attachments: 4377.txt {noformat} cqlsh create keyspace test with strategy_class = 'SimpleStrategy' and strategy_options:replication_factor = 1; cqlsh use test; cqlsh:test CREATE TABLE stats ( ... gid blob, ... period int, ... tid blob, ... sumint, ... uniques blob, ... PRIMARY KEY(gid, period, tid) ... ); cqlsh:test describe columnfamily stats; CREATE TABLE stats ( gid blob PRIMARY KEY ) WITH comment='' AND comparator='CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.UTF8Type)' AND read_repair_chance=0.10 AND gc_grace_seconds=864000 AND default_validation=text AND min_compaction_threshold=4 AND max_compaction_threshold=32 AND replicate_on_write='true' AND compaction_strategy_class='SizeTieredCompactionStrategy' AND compression_parameters:sstable_compression='SnappyCompressor'; {noformat} You can see in the above output that the stats cf is created with the column validator set to text, but neither of the non primary key columns defined are text. It should either be setting metadata for those columns or not setting a default validator or some combination of the two. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4284) Improve timeuuid - date relationship
[ https://issues.apache.org/jira/browse/CASSANDRA-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411307#comment-13411307 ] Sylvain Lebresne commented on CASSANDRA-4284: - Having though more about this issue, I'm afraid it might not be that simple. Picking a random 'clock and sequence' part when converting a time to a TimeUUID would work well for insertions, but wouldn't for queries. Typically a query like SELECT ... WHERE uuid = '2012-06-06 12:03:00+' and uuid '2012-06-06 12:03:03+' would potentially miss some rows if we timeuuid generated from those two dates has some random part. Note that this doesn't change the fact that imho our currently timeuuid/data relationship is confusing, as proved by the following comment http://www.datastax.com/dev/blog/cql3-evolutions#comment-80758. I'll also remark that if we were to extend the date syntax, this could help the problem above, since we would use something like '2012-06-06 12:03:00+ %%' where the '%%' would mean 'generate a random part for the rest of the timeuuid'. But I see this data extension doesn't gather much enthusiasm. But if we don't do anything here, I would be of the opinion of making cqlsh stop interpreting timeuuid as date by default because I'm afraid it will confuse more people than it will help. bq. sounds messy wrt the general to/from string api in AbstractType Can you elaborate on that argument? (I'm not sure I see why it would mess with the to/from string api particularly) Improve timeuuid - date relationship -- Key: CASSANDRA-4284 URL: https://issues.apache.org/jira/browse/CASSANDRA-4284 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Fix For: 1.2 We added timeuuid to CQL3, whose purpose is to provide a collision-free timestamp basically and as a convenience, such timeuuid can be inputed as as date. However, two things seems non-optimal to me: * When one insert a timeuuid using a date format, we always pick *the* UUID corresponding to this date with every other part of the UUID to 0. This kind of defeat the purpose of collision-free timestamp and thus greatly limit the usefulness of the date syntax. * When cqlsh print timeuuid, it print them as date. But as thus, there is some information lost which can be problematic (you can't update a specific column based on that return). In a way, this is a cqlsh limitation, since cassandra return the UUID bytes. Yet, it also emphasis somehow that from the point of using them, timeuuid are more UUID than really time. For the first point, it would make more sense that when inserting a date, we actually pick a uuid with the corresponding timestamp *but* with the rest of the UUID being random. It's not completely that simple because we don't want that randomness when the date are used in a select query, but that's roughtly the same problem than CASSANDRA-4283 (and we can thus use the same solution). The second point gives an idea. We could extends the date syntax to allow it to represent uniquely a type 1 UUID. Typically, we could allow something like: '2012-06-06 12:03:00+ %a2fc07', where the part after the '%' character would be hexadecimal for the non-timestamp part of the UUID. Understanding this syntax could allow to work with timeuuid uniquely with meaningful date string which I think would be neat. But maybe that's a crazy idea, opinions? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4419) leveled compaction generates too small sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-4419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4419: Attachment: 4419.txt Patch that extract the relevant part from CASSANDRA-4341. leveled compaction generates too small sstables --- Key: CASSANDRA-4419 URL: https://issues.apache.org/jira/browse/CASSANDRA-4419 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.10 Reporter: Noa Resare Priority: Minor Fix For: 1.0.11 Attachments: 4419.txt When I set sstable_size_in_mb to 96 I end up with sstable data files no larger than 60M. This in turn messes up the LeveledManifest calculation since it finds compaction candidates by summing up the size of sstables at a particular level and comparing it to the configured size multiplied by the desired number of sstables at a level, resulting in ~20 sstables in level 1 instead of the 10 that one would expect from looking at LeveledManifest. Some additional logging here reveals that the position parameter passed to LeveledCompactionTask.newSSTableSegmentThresholdReached() is significantly higher than the size of the output file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4411) Assertion with LCS compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411423#comment-13411423 ] Rudolf VanderLeeden commented on CASSANDRA-4411: I could reproduce the problem on a 3-node testcluster with 1.1.2 and LCS. Replication factor is 3 and number of total keys is 24m. I added SSTables from a previous backup to node1. Then running on node1: nodetool repair -pr Result: INFO [CompactionExecutor:7] 2012-07-11 10:06:57,632 CompactionTask.java (line 109) Compacting [SSTableReader(path='/mnt/cassandra/data/highscores/highscore/highscores-highscore-hd-4937-Data.db')] INFO [CompactionExecutor:7] 2012-07-11 10:06:58,601 CompactionTask.java (line 221) Compacted to [/mnt/cassandra/data/highscores/highscore/highscores-highscore-hd-5591-Data.db,]. 5,252,617 to 5,252,617 (~100% of original) bytes for 51,419 keys at 5.174882MB/s. Time: 968ms. INFO [CompactionExecutor:6] 2012-07-11 10:06:58,602 CompactionTask.java (line 109) Compacting [SSTableReader(path='/mnt/cassandra/data/highscores/highscore/highscores-highscore-hd-5590-Data.db'), SSTableReader(path='/mnt/cassandra/data/highscores/highscore/highscores-highscore-hd-5571-Data.db')] ERROR [CompactionExecutor:6] 2012-07-11 10:06:59,655 AbstractCassandraDaemon.java (line 134) Exception in thread Thread[CompactionExecutor:6,1,main] java.lang.AssertionError at org.apache.cassandra.db.compaction.LeveledManifest.promote(LeveledManifest.java:214) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.handleNotification(LeveledCompactionStrategy.java:158) at org.apache.cassandra.db.DataTracker.notifySSTablesChanged(DataTracker.java:531) at org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:254) at org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:978) at org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:200) at org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:50) at org.apache.cassandra.db.compaction.CompactionManager$1.runMayThrow(CompactionManager.java:150) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) 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) The next repair command throws the following assertion: ERROR [ValidationExecutor:2] 2012-07-11 10:31:28,020 AbstractCassandraDaemon.java (line 134) Exception in thread Thread[ValidationExecutor:2,1,main] java.lang.AssertionError: row DecoratedKey(162957119114255422766928006879345246467, c9e91cfb77634f32b9399dd4ad6b784e93dec9d0b11f431dad58a35e9f623de9) received out of order wrt DecoratedKey(165755005851296361665897424577644629314, ac63200da3fb452ca0b57a648b90c8a427a3d45b2d2146e089c6d04b959bb207) at org.apache.cassandra.service.AntiEntropyService$Validator.add(AntiEntropyService.java:349) at org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:712) ...etc... Let me know if you need more from the log. Thanks, -Rudolf. Assertion with LCS compaction - Key: CASSANDRA-4411 URL: https://issues.apache.org/jira/browse/CASSANDRA-4411 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.2 Reporter: Anton Winter Fix For: 1.1.3 As instructed in CASSANDRA-4321 I have raised this issue as a continuation of that issue as it appears the problem still exists. I have repeatedly run sstablescrub across all my nodes after the 1.1.2 upgrade until sstablescrub shows no errors. The exceptions described in CASSANDRA-4321 do not occur as frequently now but the integrity check still throws exceptions on a number of nodes. Once those exceptions occur compactionstats shows a large number of pending tasks with no progression afterwards. {code} ERROR [CompactionExecutor:150] 2012-07-05 04:26:15,570 AbstractCassandraDaemon.java (line 134) Exception in thread Thread[CompactionExecutor:150,1,main] java.lang.AssertionError at org.apache.cassandra.db.compaction.LeveledManifest.promote(LeveledManifest.java:214) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.handleNotification(LeveledCompactionStrategy.java:158) at
[jira] [Updated] (CASSANDRA-4411) Assertion with LCS compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schnidrig updated CASSANDRA-4411: --- Attachment: system.log Didn't have the old log, but I created a new keyspace and started using it until I hit the error. See attached file. Assertion with LCS compaction - Key: CASSANDRA-4411 URL: https://issues.apache.org/jira/browse/CASSANDRA-4411 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.2 Reporter: Anton Winter Fix For: 1.1.3 Attachments: system.log As instructed in CASSANDRA-4321 I have raised this issue as a continuation of that issue as it appears the problem still exists. I have repeatedly run sstablescrub across all my nodes after the 1.1.2 upgrade until sstablescrub shows no errors. The exceptions described in CASSANDRA-4321 do not occur as frequently now but the integrity check still throws exceptions on a number of nodes. Once those exceptions occur compactionstats shows a large number of pending tasks with no progression afterwards. {code} ERROR [CompactionExecutor:150] 2012-07-05 04:26:15,570 AbstractCassandraDaemon.java (line 134) Exception in thread Thread[CompactionExecutor:150,1,main] java.lang.AssertionError at org.apache.cassandra.db.compaction.LeveledManifest.promote(LeveledManifest.java:214) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.handleNotification(LeveledCompactionStrategy.java:158) at org.apache.cassandra.db.DataTracker.notifySSTablesChanged(DataTracker.java:531) at org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:254) at org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:978) at org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:200) at org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:50) at org.apache.cassandra.db.compaction.CompactionManager$1.runMayThrow(CompactionManager.java:150) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) 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) {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4208) ColumnFamilyOutputFormat should support writing to multiple column families
[ https://issues.apache.org/jira/browse/CASSANDRA-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411459#comment-13411459 ] Robbie Strickland commented on CASSANDRA-4208: -- I'd like to know if this is going to be included or if another direction is preferred. Any update? ColumnFamilyOutputFormat should support writing to multiple column families --- Key: CASSANDRA-4208 URL: https://issues.apache.org/jira/browse/CASSANDRA-4208 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 1.1.0 Reporter: Robbie Strickland Attachments: cassandra-1.1-4208-v2.txt, cassandra-1.1-4208-v3.txt, cassandra-1.1-4208.txt, trunk-4208-v2.txt, trunk-4208.txt It is not currently possible to output records to more than one column family in a single reducer. Considering that writing values to Cassandra often involves multiple column families (i.e. updating your index when you insert a new value), this seems overly restrictive. I am submitting a patch that moves the specification of column family from the job configuration to the write() call in ColumnFamilyRecordWriter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4125) Update nodetool for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411493#comment-13411493 ] Brandon Williams commented on CASSANDRA-4125: - bq. Is this because it's one aspect of monitoring / maintaining balance between the nodes? More as a quick check since, even with vnodes, you can create a large imbalance via fat rows. bq. Do you think this will be less relevant now? To some degree, but not completely. I think new users want to be able to see how much space their cluster is using at a glance, and foresee a lot of complaints if we remove it at this point. Also, it's easier to say send me your ring output than send me the ring output, then the output of info from each node and space used is still pertinent information to have, outside of balance issues. Update nodetool for vnodes -- Key: CASSANDRA-4125 URL: https://issues.apache.org/jira/browse/CASSANDRA-4125 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Sam Overton Assignee: Eric Evans The proposed changes are intended to preserve backwards compatibility: || op || behaviour || deprecated warning? | join | Join the ring, use with {{-t}} to join at a specific token, or to add a token to an existing host | | ring | prints the first token for each node, add {{-a}} to print all tokens | | move new token | if the node only has 1 token then move it. Otherwise die with an error. | *deprecated* | removetoken status/force/token | removes the node who owns token from the ring. use {{-t}} option to only remove the token from the node instead of the whole node. | | describering [keyspace] | show all ranges and their endpoints | | getendpoints keyspace cf key | Print the endpoints that own the key and also their list of tokens | _Edit0: Appended patch information._ h3. Patches ||Compare||Raw diff||Description|| |[01_admin_tools|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools]|[01_admin_tools.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools.diff]|Updated nodetool| _Note: These are branches managed with TopGit. If you are applying the patch output manually, you will either need to filter the TopGit metadata files (i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), or remove them afterward ({{rm .topmsg .topdeps}})._ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4144) Pig: Composite column support for row key
[ https://issues.apache.org/jira/browse/CASSANDRA-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411506#comment-13411506 ] Brandon Williams commented on CASSANDRA-4144: - I think this is only going to work for reading, but not writing. We don't have any unit tests for CS, but there are end-to-end tests in examples/pig/test where we usually try to test the 'copy CF' scenario for various types. Pig: Composite column support for row key - Key: CASSANDRA-4144 URL: https://issues.apache.org/jira/browse/CASSANDRA-4144 Project: Cassandra Issue Type: Improvement Components: Contrib Affects Versions: 1.0.9 Reporter: janwar dinata Priority: Minor Labels: Pig, hadoop Attachments: 0001-Add-support-for-composite-row-keys-in-Cassandra-PIG.patch Currently Pig only understands composite columns not composite row keys. Support for querying column family that has composite type for its key_validation_class will be nice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[1/3] git commit: Merge branch 'cassandra-1.1' into trunk
Updated Branches: refs/heads/cassandra-1.1 346ac03c2 - a12aa0815 refs/heads/trunk 8e503d8d9 - 6ab4bd7a1 Merge branch 'cassandra-1.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6ab4bd7a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6ab4bd7a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6ab4bd7a Branch: refs/heads/trunk Commit: 6ab4bd7a1a357a2709d6958f6c153270c3a4f8fa Parents: 8e503d8 a12aa08 Author: Brandon Williams brandonwilli...@apache.org Authored: Wed Jul 11 09:28:56 2012 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Wed Jul 11 09:28:56 2012 -0500 -- conf/cassandra-env.sh |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6ab4bd7a/conf/cassandra-env.sh --
[2/3] git commit: If detected cores is zero, try at least one. Patch by Andy Cobley, reviewed by brandonwilliams for CASSANDRA-4401
If detected cores is zero, try at least one. Patch by Andy Cobley, reviewed by brandonwilliams for CASSANDRA-4401 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a12aa081 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a12aa081 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a12aa081 Branch: refs/heads/trunk Commit: a12aa08154faaae7e096d8a6f500d1b352ef94b8 Parents: 346ac03 Author: Brandon Williams brandonwilli...@apache.org Authored: Wed Jul 11 09:27:26 2012 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Wed Jul 11 09:27:26 2012 -0500 -- conf/cassandra-env.sh |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a12aa081/conf/cassandra-env.sh -- diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh index a3ca022..cef0efb 100644 --- a/conf/cassandra-env.sh +++ b/conf/cassandra-env.sh @@ -41,6 +41,12 @@ calculate_heap_sizes() ;; esac +# some systems like the raspberry pi don't report cores, use at least 1 +if [ $system_cpu_cores -lt 1 ] +then +system_cpu_cores=1 +fi + # set max heap size based on the following # max(min(1/2 ram, 1024MB), min(1/4 ram, 8GB)) # calculate 1/2 ram and cap to 1024MB
[1/3] git commit: Merge branch 'cassandra-1.1' into trunk
Updated Branches: refs/heads/cassandra-1.1 a12aa0815 - 3e4858271 refs/heads/trunk 6ab4bd7a1 - ee5c09a85 Merge branch 'cassandra-1.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ee5c09a8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ee5c09a8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ee5c09a8 Branch: refs/heads/trunk Commit: ee5c09a857b646fff2dbfb1e592dbaf082d2cfea Parents: 6ab4bd7 3e48582 Author: Brandon Williams brandonwilli...@apache.org Authored: Wed Jul 11 09:44:27 2012 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Wed Jul 11 09:44:27 2012 -0500 -- bin/cqlsh | 13 - pylib/cqlshlib/cql3handling.py | 15 --- 2 files changed, 16 insertions(+), 12 deletions(-) --
[2/3] git commit: cqlsh: describe command outputs valid CQL. Patch by paul cannon, reviewed by brandonwilliams for CASSANDRA-4380
cqlsh: describe command outputs valid CQL. Patch by paul cannon, reviewed by brandonwilliams for CASSANDRA-4380 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3e485827 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3e485827 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3e485827 Branch: refs/heads/trunk Commit: 3e4858271d2c2f3f9a6ab4a13f6a48f63b77aa70 Parents: a12aa08 Author: Brandon Williams brandonwilli...@apache.org Authored: Wed Jul 11 09:38:22 2012 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Wed Jul 11 09:38:22 2012 -0500 -- bin/cqlsh | 13 - pylib/cqlshlib/cql3handling.py | 15 --- 2 files changed, 16 insertions(+), 12 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3e485827/bin/cqlsh -- diff --git a/bin/cqlsh b/bin/cqlsh index 842a313..574d49b 100755 --- a/bin/cqlsh +++ b/bin/cqlsh @@ -1187,7 +1187,7 @@ class Shell(cmd.Cmd): for cf in ksdef.cf_defs: out.write('\n') # yes, cf might be looked up again. oh well. -self.print_recreate_columnfamily(ksname, cf.name, out) +self.print_recreate_columnfamily(ksdef.name, cf.name, out) def print_recreate_columnfamily(self, ksname, cfname, out): @@ -1201,13 +1201,9 @@ class Shell(cmd.Cmd): # no metainfo available from system.schema_* for system CFs, so we have -# to use cfdef-based description for those. also, use cfdef-based -# description when the CF doesn't have a composite key. that seems like -# an ok compromise between hiding comparator, -# default_validation_class, etc for cql3, and still allowing users -# to work with old cql2-style wide tables. +# to use cfdef-based description for those. -if cfname != 'system' \ +if ksname != 'system' \ and self.cqlver_atleast(3): try: layout = self.get_columnfamily_layout(ksname, cfname) @@ -1215,8 +1211,7 @@ class Shell(cmd.Cmd): # most likely a 1.1 beta where cql3 is supported, but not system.schema_* pass else: -if len(layout.key_components) 1: -return self.print_recreate_columnfamily_from_layout(layout, out) +return self.print_recreate_columnfamily_from_layout(layout, out) cfdef = self.get_columnfamily(cfname, ksname=ksname) return self.print_recreate_columnfamily_from_cfdef(cfdef, out) http://git-wip-us.apache.org/repos/asf/cassandra/blob/3e485827/pylib/cqlshlib/cql3handling.py -- diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py index 2bc7ef9..1628c66 100644 --- a/pylib/cqlshlib/cql3handling.py +++ b/pylib/cqlshlib/cql3handling.py @@ -41,6 +41,17 @@ class Cql3ParsingRuleSet(CqlParsingRuleSet): 'compact', 'storage', 'order', 'by', 'asc', 'desc', 'clustering', 'token' )) +columnfamily_options = ( +# (CQL option name, Thrift option name (or None if same)) +('comment', None), +('comparator', 'comparator_type'), +('read_repair_chance', None), +('gc_grace_seconds', None), +('default_validation', 'default_validation_class'), +('replicate_on_write', None), +('compaction_strategy_class', 'compaction_strategy'), +) + columnfamily_layout_options = ( 'comment', 'bloom_filter_fp_chance', @@ -48,8 +59,6 @@ class Cql3ParsingRuleSet(CqlParsingRuleSet): 'read_repair_chance', # 'local_read_repair_chance', -- not yet a valid cql option 'gc_grace_seconds', -'min_compaction_threshold', -'max_compaction_threshold', 'replicate_on_write', 'compaction_strategy_class', ) @@ -90,7 +99,7 @@ class Cql3ParsingRuleSet(CqlParsingRuleSet): def cql3_escape_name(name): return '%s' % name.replace('', '') -valid_cql3_word_re = re.compile(r'^[a-z][0-9a-z_]*$', re.I) +valid_cql3_word_re = re.compile(r'^[a-z][0-9a-z_]*$') @classmethod def is_valid_cql3_name(cls, s):
[3/3] git commit: cqlsh: describe command outputs valid CQL. Patch by paul cannon, reviewed by brandonwilliams for CASSANDRA-4380
cqlsh: describe command outputs valid CQL. Patch by paul cannon, reviewed by brandonwilliams for CASSANDRA-4380 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3e485827 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3e485827 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3e485827 Branch: refs/heads/cassandra-1.1 Commit: 3e4858271d2c2f3f9a6ab4a13f6a48f63b77aa70 Parents: a12aa08 Author: Brandon Williams brandonwilli...@apache.org Authored: Wed Jul 11 09:38:22 2012 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Wed Jul 11 09:38:22 2012 -0500 -- bin/cqlsh | 13 - pylib/cqlshlib/cql3handling.py | 15 --- 2 files changed, 16 insertions(+), 12 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3e485827/bin/cqlsh -- diff --git a/bin/cqlsh b/bin/cqlsh index 842a313..574d49b 100755 --- a/bin/cqlsh +++ b/bin/cqlsh @@ -1187,7 +1187,7 @@ class Shell(cmd.Cmd): for cf in ksdef.cf_defs: out.write('\n') # yes, cf might be looked up again. oh well. -self.print_recreate_columnfamily(ksname, cf.name, out) +self.print_recreate_columnfamily(ksdef.name, cf.name, out) def print_recreate_columnfamily(self, ksname, cfname, out): @@ -1201,13 +1201,9 @@ class Shell(cmd.Cmd): # no metainfo available from system.schema_* for system CFs, so we have -# to use cfdef-based description for those. also, use cfdef-based -# description when the CF doesn't have a composite key. that seems like -# an ok compromise between hiding comparator, -# default_validation_class, etc for cql3, and still allowing users -# to work with old cql2-style wide tables. +# to use cfdef-based description for those. -if cfname != 'system' \ +if ksname != 'system' \ and self.cqlver_atleast(3): try: layout = self.get_columnfamily_layout(ksname, cfname) @@ -1215,8 +1211,7 @@ class Shell(cmd.Cmd): # most likely a 1.1 beta where cql3 is supported, but not system.schema_* pass else: -if len(layout.key_components) 1: -return self.print_recreate_columnfamily_from_layout(layout, out) +return self.print_recreate_columnfamily_from_layout(layout, out) cfdef = self.get_columnfamily(cfname, ksname=ksname) return self.print_recreate_columnfamily_from_cfdef(cfdef, out) http://git-wip-us.apache.org/repos/asf/cassandra/blob/3e485827/pylib/cqlshlib/cql3handling.py -- diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py index 2bc7ef9..1628c66 100644 --- a/pylib/cqlshlib/cql3handling.py +++ b/pylib/cqlshlib/cql3handling.py @@ -41,6 +41,17 @@ class Cql3ParsingRuleSet(CqlParsingRuleSet): 'compact', 'storage', 'order', 'by', 'asc', 'desc', 'clustering', 'token' )) +columnfamily_options = ( +# (CQL option name, Thrift option name (or None if same)) +('comment', None), +('comparator', 'comparator_type'), +('read_repair_chance', None), +('gc_grace_seconds', None), +('default_validation', 'default_validation_class'), +('replicate_on_write', None), +('compaction_strategy_class', 'compaction_strategy'), +) + columnfamily_layout_options = ( 'comment', 'bloom_filter_fp_chance', @@ -48,8 +59,6 @@ class Cql3ParsingRuleSet(CqlParsingRuleSet): 'read_repair_chance', # 'local_read_repair_chance', -- not yet a valid cql option 'gc_grace_seconds', -'min_compaction_threshold', -'max_compaction_threshold', 'replicate_on_write', 'compaction_strategy_class', ) @@ -90,7 +99,7 @@ class Cql3ParsingRuleSet(CqlParsingRuleSet): def cql3_escape_name(name): return '%s' % name.replace('', '') -valid_cql3_word_re = re.compile(r'^[a-z][0-9a-z_]*$', re.I) +valid_cql3_word_re = re.compile(r'^[a-z][0-9a-z_]*$') @classmethod def is_valid_cql3_name(cls, s):
[jira] [Commented] (CASSANDRA-4401) If processor is missing from /proc/cpuinfo, cassandra will not start
[ https://issues.apache.org/jira/browse/CASSANDRA-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411587#comment-13411587 ] Andy Cobley commented on CASSANDRA-4401: Good idea ! If processor is missing from /proc/cpuinfo, cassandra will not start Key: CASSANDRA-4401 URL: https://issues.apache.org/jira/browse/CASSANDRA-4401 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 1.1.1 Reporter: Andy Cobley Priority: Minor Fix For: 1.1.3 Attachments: 4401.txt cassandra.env.sh does an egrep on /proc/cpuinfo in order to find the number of processors on the system. If /proc/cpuinfo does not contain a processor :# line then the script will fail because of a divide by 0 error. Changing the Linux section of cassandra.env.sh to: Linux) system_memory_in_mb=`free -m | awk '/Mem:/ {print $2}'` system_cpu_cores=`egrep -c 'processor([[:space:]]+):.*' /proc/cpuinfo` if [ $system_cpu_cores -lt 1 ] then system_cpu_cores=1 fi is a possible fix -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of GettingStarted by JonathanEllis
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The GettingStarted page has been changed by JonathanEllis: http://wiki.apache.org/cassandra/GettingStarted?action=diffrev1=67rev2=68 == Cassandra documentation from DataStax == - !DataStax's latest [[http://www.datastax.com/docs/1.0/index|Cassandra documentation]] covers topics from installation to troubleshooting. Documentation for older releases is also available. + !DataStax's latest [[http://www.datastax.com/docs/1.1/index|Cassandra documentation]] covers topics from installation to troubleshooting. Documentation for older releases is also available. == Introduction == This document aims to provide a few easy to follow steps to take the first-time user from installation, to running single node Cassandra, and overview to configure multinode cluster.
[2/3] git commit: remove redundant name column from schema_keyspaces patch by jbellis; reviewed by xedin for CASSANDRA-4433
remove redundant name column from schema_keyspaces patch by jbellis; reviewed by xedin for CASSANDRA-4433 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/326312b5 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/326312b5 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/326312b5 Branch: refs/heads/trunk Commit: 326312b5db746ecfac19275d560a19c1bfc6362f Parents: 629dac6 Author: Jonathan Ellis jbel...@apache.org Authored: Tue Jul 10 20:18:58 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Jul 11 11:15:56 2012 -0500 -- CHANGES.txt|1 + .../org/apache/cassandra/config/CFMetaData.java|1 - .../org/apache/cassandra/config/KSMetaData.java|3 +-- 3 files changed, 2 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/326312b5/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 8957d6c..50a0bcd 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.2-dev + * remove redundant name column from schema_keyspaces (CASSANDRA-4433) * improve nodetool ring handling of multi-dc clusters (CASSANDRA-3047) * update NTS calculateNaturalEndpoints to be O(N log N) (CASSANDRA-3881) * add UseCondCardMark XX jvm settings on jdk 1.7 (CASSANDRA-4366) http://git-wip-us.apache.org/repos/asf/cassandra/blob/326312b5/src/java/org/apache/cassandra/config/CFMetaData.java -- diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java b/src/java/org/apache/cassandra/config/CFMetaData.java index 9e10ee2..fb9ae88 100644 --- a/src/java/org/apache/cassandra/config/CFMetaData.java +++ b/src/java/org/apache/cassandra/config/CFMetaData.java @@ -103,7 +103,6 @@ public final class CFMetaData // new-style schema public static final CFMetaData SchemaKeyspacesCf = compile(8, CREATE TABLE + SystemTable.SCHEMA_KEYSPACES_CF + ( + keyspace_name text PRIMARY KEY, - + name text, // TODO + durable_writes boolean, + strategy_class text, + strategy_options text http://git-wip-us.apache.org/repos/asf/cassandra/blob/326312b5/src/java/org/apache/cassandra/config/KSMetaData.java -- diff --git a/src/java/org/apache/cassandra/config/KSMetaData.java b/src/java/org/apache/cassandra/config/KSMetaData.java index 94de5a2..a7cdda3 100644 --- a/src/java/org/apache/cassandra/config/KSMetaData.java +++ b/src/java/org/apache/cassandra/config/KSMetaData.java @@ -220,7 +220,6 @@ public final class KSMetaData RowMutation rm = new RowMutation(Table.SYSTEM_TABLE, SystemTable.getSchemaKSKey(name)); ColumnFamily cf = rm.addOrGet(SystemTable.SCHEMA_KEYSPACES_CF); -cf.addColumn(Column.create(name, timestamp, name)); cf.addColumn(Column.create(durableWrites, timestamp, durable_writes)); cf.addColumn(Column.create(strategyClass.getName(), timestamp, strategy_class)); cf.addColumn(Column.create(json(strategyOptions), timestamp, strategy_options)); @@ -245,7 +244,7 @@ public final class KSMetaData UntypedResultSet.Row result = QueryProcessor.resultify(SELECT * FROM system.schema_keyspaces, row).one(); try { -return new KSMetaData(result.getString(name), +return new KSMetaData(result.getString(keyspace_name), AbstractReplicationStrategy.getClass(result.getString(strategy_class)), fromJsonMap(result.getString(strategy_options)), result.getBoolean(durable_writes),
[1/3] git commit: update README to cql
Updated Branches: refs/heads/trunk ee5c09a85 - 54a3d5395 update README to cql Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/54a3d539 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/54a3d539 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/54a3d539 Branch: refs/heads/trunk Commit: 54a3d5395650830104fc5e7c1b5162dec66a0057 Parents: 326312b Author: Jonathan Ellis jbel...@apache.org Authored: Wed Jul 11 11:38:54 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Jul 11 11:38:54 2012 -0500 -- README.txt | 86 -- 1 files changed, 38 insertions(+), 48 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/54a3d539/README.txt -- diff --git a/README.txt b/README.txt index 3985a98..3391f64 100644 --- a/README.txt +++ b/README.txt @@ -1,3 +1,5 @@ + + Cassandra is a highly scalable, eventually consistent, distributed, structured key-value store. @@ -48,66 +50,54 @@ environment variable to the full path of prunsrv (e.g., C:\procrun\prunsrv.exe), and run bin\cassandra.bat install. Similarly, uninstall will remove the service. -Now let's try to read and write some data using the command line client. +Now let's try to read and write some data using the Cassandra Query Language: - * bin/cassandra-cli --host localhost + * bin/cqlsh --cql3 The command line client is interactive so if everything worked you should be sitting in front of a prompt... - Connected to: Test Cluster on localhost/9160 - Welcome to cassandra CLI. + Connected to Test Cluster at localhost:9160. + [cqlsh 2.2.0 | Cassandra 1.1.3 | CQL spec 3.0.0 | Thrift protocol 19.32.0] + Use HELP for help. + cqlsh + - Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit. - [default@unknown] - -As the banner says, you can use 'help;' or '?' to see what the CLI has to +As the banner says, you can use 'help;' or '?' to see what CQL has to offer, and 'quit;' or 'exit;' when you've had enough fun. But lets try -something slightly more interesting... - - [default@unknown] create keyspace Keyspace1; - ece86bde-dc55-11df-8240-e700f669bcfc - [default@unknown] use Keyspace1; - Authenticated to keyspace: Keyspace1 - [default@Keyspace1] create column family Users with comparator=UTF8Type and default_validation_class=UTF8Type and key_validation_class=UTF8Type; - 737c7a71-dc56-11df-8240-e700f669bcfc - - [default@KS1] set Users[jsmith][first] = 'John'; - Value inserted. - [default@KS1] set Users[jsmith][last] = 'Smith'; - Value inserted. - [default@KS1] set Users[jsmith][age] = long(42); - Value inserted. - [default@KS1] get Users[jsmith]; - = (column=last, value=Smith, timestamp=1287604215498000) - = (column=first, value=John, timestamp=1287604214111000) - = (column=age, value=42, timestamp=1287604216661000) - Returned 3 results. +something slightly more interesting: + + cqlsh CREATE SCHEMA schema1 + WITH strategy_class = 'SimpleStrategy' + AND strategy_options:replication_factor='1'; + cqlsh USE schema1; + cqlsh:Schema1 CREATE TABLE users ( + user_id varchar PRIMARY KEY, + first varchar, + last varchar, + age int + ); + cqlsh:Schema1 INSERT INTO users (user_id, first, last, age) + VALUES ('jsmith', 'John', 'Smith', 42); + cqlsh:Schema1 SELECT * FROM users; + user_id | age | first | last + -+-+---+--- +jsmith | 42 | john | smith + + cqlsh:Schema1 If your session looks similar to what's above, congrats, your single node -cluster is operational! But what exactly was all of that? Let's break it -down into pieces and see. - - set Users[jsmith][first] = 'John'; -\ \\ \ - \ \_ key \ \_ value - \ \_ column - \_ column family +cluster is operational! -Data stored in Cassandra is associated with a column family (Users), -which in turn is associated with a keyspace (Keyspace1). In the example -above, we set the value 'John' in the 'first' column for key 'jsmith'. - -For more information on the Cassandra data model be sure to checkout -http://wiki.apache.org/cassandra/DataModel +For more on what commands are supported by CQL, see +https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile. A +reasonable way to think of it is as, SQL minus joins and subqueries. Wondering where to go from here? - * The wiki (http://wiki.apache.org/cassandra/) is the -best source for additional information. - * Join us in #cassandra on irc.freenode.net and ask questions. + *
[3/3] git commit: formatting
formatting Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/629dac6c Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/629dac6c Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/629dac6c Branch: refs/heads/trunk Commit: 629dac6c8aeeb5649ebb640ab0c6334b24eee85d Parents: ee5c09a Author: Jonathan Ellis jbel...@apache.org Authored: Tue Jul 10 15:33:11 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Jul 11 11:15:55 2012 -0500 -- .../apache/cassandra/db/ColumnFamilyStoreTest.java | 20 ++- 1 files changed, 8 insertions(+), 12 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/629dac6c/test/unit/org/apache/cassandra/db/ColumnFamilyStoreTest.java -- diff --git a/test/unit/org/apache/cassandra/db/ColumnFamilyStoreTest.java b/test/unit/org/apache/cassandra/db/ColumnFamilyStoreTest.java index 0549f65..95aa446 100644 --- a/test/unit/org/apache/cassandra/db/ColumnFamilyStoreTest.java +++ b/test/unit/org/apache/cassandra/db/ColumnFamilyStoreTest.java @@ -1354,7 +1354,6 @@ public class ColumnFamilyStoreTest extends SchemaLoader // printRow(cfs, new String(row.key.key.array()), cols); String[] returnedColsNames = Iterables.toArray(Iterables.transform(cols, new FunctionIColumn, String() { -@Override public String apply(IColumn arg0) { return new String(arg0.name().array()); @@ -1379,22 +1378,19 @@ public class ColumnFamilyStoreTest extends SchemaLoader System.err.println(Row key: + rowKey + Cols: + Iterables.transform(cf.getSortedColumns(), new FunctionIColumn, String() { -@Override public String apply(IColumn arg0) { return new String(arg0.name().array()); } })); System.err.println(Filtered:); -System.err.println(Row key: + rowKey + Cols: -+ Iterables.transform(cols, new FunctionIColumn, String() -{ -@Override -public String apply(IColumn arg0) -{ -return new String(arg0.name().array()); -} -})); +IterableString transformed = Iterables.transform(cols, new FunctionIColumn, String() +{ +public String apply(IColumn arg0) +{ +return new String(arg0.name().array()); +} +}); +System.err.println(Row key: + rowKey + Cols: + transformed); } - }
[jira] [Updated] (CASSANDRA-4054) SStableImport and SStableExport does not serialize row level deletion
[ https://issues.apache.org/jira/browse/CASSANDRA-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves updated CASSANDRA-4054: --- Attachment: 4054.patch patch without abbreviated names SStableImport and SStableExport does not serialize row level deletion - Key: CASSANDRA-4054 URL: https://issues.apache.org/jira/browse/CASSANDRA-4054 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.5 Reporter: Zhu Han Assignee: David Alves Priority: Minor Fix For: 1.2 Attachments: 4054.patch, 4054.patch, 4054.patch SSTableImport and SSTableExport does not serialize/de-serialize the row-level deletion info to/from the json file. This brings back the deleted data after restore from the json file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4127) migration support for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411809#comment-13411809 ] Jonathan Ellis commented on CASSANDRA-4127: --- bq. This will allow a rolling migration where N new hosts are bootstrapped into the cluster (with num_tokens set appropriately) and then the N old nodes are decommissioned. That's a fairly painful / expensive proposition. Since we already have vnode migration for bootstrap / decommission, couldn't we just add a {{nodetool shuffle}} command to do that in-place instead? migration support for vnodes Key: CASSANDRA-4127 URL: https://issues.apache.org/jira/browse/CASSANDRA-4127 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Sam Overton Assignee: Sam Overton Labels: vnodes If, when starting up for the first time, the host only has 1 token but num_tokens is configured differently, then this will trigger a migration process: * The host will assign itself num_tokens tokens in its own range * The new tokens will be gossiped This will allow a rolling migration where N new hosts are bootstrapped into the cluster (with num_tokens set appropriately) and then the N old nodes are decommissioned. This will result in even distribution of the data among the new nodes with randomly assigned tokens. _Edit0: Appended patch information._ h3. Patches ||Compare||Raw diff||Description|| |[01_migration_path|https://github.com/acunu/cassandra/compare/top-bases/p/4127/01_migration_path...p/4127/01_migration_path]|[01_migration_path.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4127/01_migration_path...p/4127/01_migration_path.diff]|Migrate from one token to many| _Note: These are branches managed with TopGit. If you are applying the patch output manually, you will either need to filter the TopGit metadata files (i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), or remove them afterward ({{rm .topmsg .topdeps}})._ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4125) Update nodetool for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411830#comment-13411830 ] Brandon Williams commented on CASSANDRA-4125: - I think we may still have a problem with ownership calculation: {{noformat}} Address Status StateLoad Tokens Owns (effective) Host ID 10.179.65.102Up Normal 197.82 MB 1 66.67% e1c24ebd-e9c0-40eb-9419-e510d849c3e0 10.179.111.137 Up Normal 197.95 MB 256 99.87% c9a17642-35dd-4eb5-9881-9631a5590a40 10.179.64.227Up Normal 197.6 MB 1 33.46% 574f6677-d7a5-405a-9fb8-5c4d829f0a10 {{noformat} .137 has 256 tokens, but they should be contiguous (upgraded) Update nodetool for vnodes -- Key: CASSANDRA-4125 URL: https://issues.apache.org/jira/browse/CASSANDRA-4125 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Sam Overton Assignee: Eric Evans The proposed changes are intended to preserve backwards compatibility: || op || behaviour || deprecated warning? | join | Join the ring, use with {{-t}} to join at a specific token, or to add a token to an existing host | | ring | prints the first token for each node, add {{-a}} to print all tokens | | move new token | if the node only has 1 token then move it. Otherwise die with an error. | *deprecated* | removetoken status/force/token | removes the node who owns token from the ring. use {{-t}} option to only remove the token from the node instead of the whole node. | | describering [keyspace] | show all ranges and their endpoints | | getendpoints keyspace cf key | Print the endpoints that own the key and also their list of tokens | _Edit0: Appended patch information._ h3. Patches ||Compare||Raw diff||Description|| |[01_admin_tools|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools]|[01_admin_tools.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools.diff]|Updated nodetool| _Note: These are branches managed with TopGit. If you are applying the patch output manually, you will either need to filter the TopGit metadata files (i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), or remove them afterward ({{rm .topmsg .topdeps}})._ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4125) Update nodetool for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411830#comment-13411830 ] Brandon Williams edited comment on CASSANDRA-4125 at 7/11/12 6:36 PM: -- I think we may still have a problem with ownership calculation: {{noformat}} Address Status StateLoad Tokens Owns (effective) Host ID 10.179.65.102Up Normal 197.82 MB 1 66.67% e1c24ebd-e9c0-40eb-9419-e510d849c3e0 10.179.111.137 Up Normal 197.95 MB 256 99.87% c9a17642-35dd-4eb5-9881-9631a5590a40 10.179.64.227Up Normal 197.6 MB 1 33.46% 574f6677-d7a5-405a-9fb8-5c4d829f0a10 {{noformat}} .137 has 256 tokens, but they should be contiguous (upgraded) was (Author: brandon.williams): I think we may still have a problem with ownership calculation: {{noformat}} Address Status StateLoad Tokens Owns (effective) Host ID 10.179.65.102Up Normal 197.82 MB 1 66.67% e1c24ebd-e9c0-40eb-9419-e510d849c3e0 10.179.111.137 Up Normal 197.95 MB 256 99.87% c9a17642-35dd-4eb5-9881-9631a5590a40 10.179.64.227Up Normal 197.6 MB 1 33.46% 574f6677-d7a5-405a-9fb8-5c4d829f0a10 {{noformat} .137 has 256 tokens, but they should be contiguous (upgraded) Update nodetool for vnodes -- Key: CASSANDRA-4125 URL: https://issues.apache.org/jira/browse/CASSANDRA-4125 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Sam Overton Assignee: Eric Evans The proposed changes are intended to preserve backwards compatibility: || op || behaviour || deprecated warning? | join | Join the ring, use with {{-t}} to join at a specific token, or to add a token to an existing host | | ring | prints the first token for each node, add {{-a}} to print all tokens | | move new token | if the node only has 1 token then move it. Otherwise die with an error. | *deprecated* | removetoken status/force/token | removes the node who owns token from the ring. use {{-t}} option to only remove the token from the node instead of the whole node. | | describering [keyspace] | show all ranges and their endpoints | | getendpoints keyspace cf key | Print the endpoints that own the key and also their list of tokens | _Edit0: Appended patch information._ h3. Patches ||Compare||Raw diff||Description|| |[01_admin_tools|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools]|[01_admin_tools.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools.diff]|Updated nodetool| _Note: These are branches managed with TopGit. If you are applying the patch output manually, you will either need to filter the TopGit metadata files (i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), or remove them afterward ({{rm .topmsg .topdeps}})._ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4125) Update nodetool for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411830#comment-13411830 ] Brandon Williams edited comment on CASSANDRA-4125 at 7/11/12 6:37 PM: -- I think we may still have a problem with ownership calculation: {noformat} Address Status StateLoad Tokens Owns (effective) Host ID 10.179.65.102Up Normal 197.82 MB 1 66.67% e1c24ebd-e9c0-40eb-9419-e510d849c3e0 10.179.111.137 Up Normal 197.95 MB 256 99.87% c9a17642-35dd-4eb5-9881-9631a5590a40 10.179.64.227Up Normal 197.6 MB 1 33.46% 574f6677-d7a5-405a-9fb8-5c4d829f0a10 {noformat} .137 has 256 tokens, but they should be contiguous (upgraded) was (Author: brandon.williams): I think we may still have a problem with ownership calculation: {{noformat}} Address Status StateLoad Tokens Owns (effective) Host ID 10.179.65.102Up Normal 197.82 MB 1 66.67% e1c24ebd-e9c0-40eb-9419-e510d849c3e0 10.179.111.137 Up Normal 197.95 MB 256 99.87% c9a17642-35dd-4eb5-9881-9631a5590a40 10.179.64.227Up Normal 197.6 MB 1 33.46% 574f6677-d7a5-405a-9fb8-5c4d829f0a10 {{noformat}} .137 has 256 tokens, but they should be contiguous (upgraded) Update nodetool for vnodes -- Key: CASSANDRA-4125 URL: https://issues.apache.org/jira/browse/CASSANDRA-4125 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Sam Overton Assignee: Eric Evans The proposed changes are intended to preserve backwards compatibility: || op || behaviour || deprecated warning? | join | Join the ring, use with {{-t}} to join at a specific token, or to add a token to an existing host | | ring | prints the first token for each node, add {{-a}} to print all tokens | | move new token | if the node only has 1 token then move it. Otherwise die with an error. | *deprecated* | removetoken status/force/token | removes the node who owns token from the ring. use {{-t}} option to only remove the token from the node instead of the whole node. | | describering [keyspace] | show all ranges and their endpoints | | getendpoints keyspace cf key | Print the endpoints that own the key and also their list of tokens | _Edit0: Appended patch information._ h3. Patches ||Compare||Raw diff||Description|| |[01_admin_tools|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools]|[01_admin_tools.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools.diff]|Updated nodetool| _Note: These are branches managed with TopGit. If you are applying the patch output manually, you will either need to filter the TopGit metadata files (i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), or remove them afterward ({{rm .topmsg .topdeps}})._ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4374) gossipinfo should print the generation
[ https://issues.apache.org/jira/browse/CASSANDRA-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-4374. - Resolution: Not A Problem Nodetool info prints the generation already, that's enough. gossipinfo should print the generation -- Key: CASSANDRA-4374 URL: https://issues.apache.org/jira/browse/CASSANDRA-4374 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1.3 As the title says. There's no way to debug token takeover problems other than TRACE without it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4284) Improve timeuuid - date relationship
[ https://issues.apache.org/jira/browse/CASSANDRA-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411844#comment-13411844 ] paul cannon commented on CASSANDRA-4284: bq. But if we don't do anything here, I would be of the opinion of making cqlsh stop interpreting timeuuid as date by default because I'm afraid it will confuse more people than it will help. I'd much rather have the % syntax addition than to do this. It seems like people using timeuuid will usually want to see the date value associated with their timeuuids, not the actual uuid value. They can still get the latter with an ASSUME, but I think that would be the exception, not the rule. We might just need to make that particular use of ASSUME more easily found (maybe put it in the CQL3 docs along with the description of timeuuid). What if we (a) filled in random bits for the MAC address area of the uuids, and (b) extended the recognized timestamp syntax to allow specifying fractional seconds? We have 7 extra digits of precision that we could be allowing users to employ. It's lots more obvious what the extra digits mean when printed, and people can understand easily how their values will sort with respect to other timeuuids. If a user inserts multiple timestamps with the exact same value (down to the 100-ns precision), then they will end up being sorted randomly with respect to each other, but the user should have no expectations about their ordering, so that's ok. Of course if the user wants to specify the entire value of the uuid, she can use the uuid syntax. Improve timeuuid - date relationship -- Key: CASSANDRA-4284 URL: https://issues.apache.org/jira/browse/CASSANDRA-4284 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Fix For: 1.2 We added timeuuid to CQL3, whose purpose is to provide a collision-free timestamp basically and as a convenience, such timeuuid can be inputed as as date. However, two things seems non-optimal to me: * When one insert a timeuuid using a date format, we always pick *the* UUID corresponding to this date with every other part of the UUID to 0. This kind of defeat the purpose of collision-free timestamp and thus greatly limit the usefulness of the date syntax. * When cqlsh print timeuuid, it print them as date. But as thus, there is some information lost which can be problematic (you can't update a specific column based on that return). In a way, this is a cqlsh limitation, since cassandra return the UUID bytes. Yet, it also emphasis somehow that from the point of using them, timeuuid are more UUID than really time. For the first point, it would make more sense that when inserting a date, we actually pick a uuid with the corresponding timestamp *but* with the rest of the UUID being random. It's not completely that simple because we don't want that randomness when the date are used in a select query, but that's roughtly the same problem than CASSANDRA-4283 (and we can thus use the same solution). The second point gives an idea. We could extends the date syntax to allow it to represent uniquely a type 1 UUID. Typically, we could allow something like: '2012-06-06 12:03:00+ %a2fc07', where the part after the '%' character would be hexadecimal for the non-timestamp part of the UUID. Understanding this syntax could allow to work with timeuuid uniquely with meaningful date string which I think would be neat. But maybe that's a crazy idea, opinions? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4419) leveled compaction generates too small sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-4419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411951#comment-13411951 ] Jonathan Ellis commented on CASSANDRA-4419: --- +1 leveled compaction generates too small sstables --- Key: CASSANDRA-4419 URL: https://issues.apache.org/jira/browse/CASSANDRA-4419 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.10 Reporter: Noa Resare Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.0.11 Attachments: 4419.txt When I set sstable_size_in_mb to 96 I end up with sstable data files no larger than 60M. This in turn messes up the LeveledManifest calculation since it finds compaction candidates by summing up the size of sstables at a particular level and comparing it to the configured size multiplied by the desired number of sstables at a level, resulting in ~20 sstables in level 1 instead of the 10 that one would expect from looking at LeveledManifest. Some additional logging here reveals that the position parameter passed to LeveledCompactionTask.newSSTableSegmentThresholdReached() is significantly higher than the size of the output file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4261) [patch] Support consistency-latency prediction in nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411958#comment-13411958 ] Jonathan Ellis commented on CASSANDRA-4261: --- bq. sending local messages avoids the PBS latency collection code path Is that a bug or a feature? :) Shouldn't local latency count as well? [patch] Support consistency-latency prediction in nodetool -- Key: CASSANDRA-4261 URL: https://issues.apache.org/jira/browse/CASSANDRA-4261 Project: Cassandra Issue Type: New Feature Components: Tools Affects Versions: 1.2 Reporter: Peter Bailis Attachments: demo-pbs-v3.sh, pbs-nodetool-v3.patch h3. Introduction Cassandra supports a variety of replication configurations: ReplicationFactor is set per-ColumnFamily and ConsistencyLevel is set per-request. Setting {{ConsistencyLevel}} to {{QUORUM}} for reads and writes ensures strong consistency, but {{QUORUM}} is often slower than {{ONE}}, {{TWO}}, or {{THREE}}. What should users choose? This patch provides a latency-consistency analysis within {{nodetool}}. Users can accurately predict Cassandra's behavior in their production environments without interfering with performance. What's the probability that we'll read a write t seconds after it completes? What about reading one of the last k writes? This patch provides answers via {{nodetool predictconsistency}}: {{nodetool predictconsistency ReplicationFactor TimeAfterWrite Versions}} \\ \\ {code:title=Example output|borderStyle=solid} //N == ReplicationFactor //R == read ConsistencyLevel //W == write ConsistencyLevel user@test:$ nodetool predictconsistency 3 100 1 Performing consistency prediction 100ms after a given write, with maximum version staleness of k=1 N=3, R=1, W=1 Probability of consistent reads: 0.678900 Average read latency: 5.377900ms (99.900th %ile 40ms) Average write latency: 36.971298ms (99.900th %ile 294ms) N=3, R=1, W=2 Probability of consistent reads: 0.791600 Average read latency: 5.372500ms (99.900th %ile 39ms) Average write latency: 303.630890ms (99.900th %ile 357ms) N=3, R=1, W=3 Probability of consistent reads: 1.00 Average read latency: 5.426600ms (99.900th %ile 42ms) Average write latency: 1382.650879ms (99.900th %ile 629ms) N=3, R=2, W=1 Probability of consistent reads: 0.915800 Average read latency: 11.091000ms (99.900th %ile 348ms) Average write latency: 42.663101ms (99.900th %ile 284ms) N=3, R=2, W=2 Probability of consistent reads: 1.00 Average read latency: 10.606800ms (99.900th %ile 263ms) Average write latency: 310.117615ms (99.900th %ile 335ms) N=3, R=3, W=1 Probability of consistent reads: 1.00 Average read latency: 52.657501ms (99.900th %ile 565ms) Average write latency: 39.949799ms (99.900th %ile 237ms) {code} h3. Demo Here's an example scenario you can run using [ccm|https://github.com/pcmanus/ccm]. The prediction is fast: {code:borderStyle=solid} cd cassandra-source-dir with patch applied ant # turn on consistency logging sed -i .bak 's/log_latencies_for_consistency_prediction: false/log_latencies_for_consistency_prediction: true/' conf/cassandra.yaml ccm create consistencytest --cassandra-dir=. ccm populate -n 5 ccm start # if start fails, you might need to initialize more loopback interfaces # e.g., sudo ifconfig lo0 alias 127.0.0.2 # use stress to get some sample latency data tools/bin/stress -d 127.0.0.1 -l 3 -n 1 -o insert tools/bin/stress -d 127.0.0.1 -l 3 -n 1 -o read bin/nodetool -h 127.0.0.1 -p 7100 predictconsistency 3 100 1 {code} h3. What and Why We've implemented [Probabilistically Bounded Staleness|http://pbs.cs.berkeley.edu/#demo], a new technique for predicting consistency-latency trade-offs within Cassandra. Our [paper|http://arxiv.org/pdf/1204.6082.pdf] will appear in [VLDB 2012|http://www.vldb2012.org/], and, in it, we've used PBS to profile a range of Dynamo-style data store deployments at places like LinkedIn and Yammer in addition to profiling our own Cassandra deployments. In our experience, prediction is both accurate and much more lightweight than profiling and manually testing each possible replication configuration (especially in production!). This analysis is important for the many users we've talked to and heard about who use partial quorum operation (e.g., non-{{QUORUM}} {{ConsistencyLevel}}). Should they use CL={{ONE}}? CL={{TWO}}? It likely depends on their runtime environment and, short of profiling in production, there's no existing way to answer these questions. (Keep in mind, Cassandra defaults to CL={{ONE}}, meaning users don't know how stale their data will be.) We outline limitations of the current approach after describing how it's
[jira] [Commented] (CASSANDRA-4421) Support cql3 table definitions in Hadoop InputFormat
[ https://issues.apache.org/jira/browse/CASSANDRA-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411965#comment-13411965 ] Jonathan Ellis commented on CASSANDRA-4421: --- bq. on the short term, can't we use the CQL processor client side to convert the select statement to a thrift query (since we know how to do this for thrift queries)? Well, we know how to convert select to StorageProxy queries, which isn't quite the same thing. So we'd probably need to shove an abstraction layer in there, which is already some pretty thick code. bq. on the slightly longer term, we will need general paging for CQL queries for CASSANDRA-4415. Once that's in, that should lift the main difficulty, shouldn't it? Yes, I think it would. Support cql3 table definitions in Hadoop InputFormat Key: CASSANDRA-4421 URL: https://issues.apache.org/jira/browse/CASSANDRA-4421 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Environment: Debian Squeeze Reporter: bert Passek Assignee: Sylvain Lebresne Labels: cql3 Fix For: 1.1.3 Hello, i faced a bug while writing composite column values and following validation on server side. This is the setup for reproduction: 1. create a keyspace create keyspace test with strategy_class = 'SimpleStrategy' and strategy_options:replication_factor = 1; 2. create a cf via cql (3.0) create table test1 ( a int, b int, c int, primary key (a, b) ); If i have a look at the schema in cli i noticed that there is no column metadata for columns not part of primary key. create column family test1 with column_type = 'Standard' and comparator = 'CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.UTF8Type)' and default_validation_class = 'UTF8Type' and key_validation_class = 'Int32Type' and read_repair_chance = 0.1 and dclocal_read_repair_chance = 0.0 and gc_grace = 864000 and min_compaction_threshold = 4 and max_compaction_threshold = 32 and replicate_on_write = true and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' and caching = 'KEYS_ONLY' and compression_options = {'sstable_compression' : 'org.apache.cassandra.io.compress.SnappyCompressor'}; Please notice the default validation class: UTF8Type Now i would like to insert value 127 via cassandra client (no cql, part of mr-jobs). Have a look at the attachement. Batch mutate fails: InvalidRequestException(why:(String didn't validate.) [test][test1][1:c] failed validation) A validator for column value is fetched in ThriftValidation::validateColumnData which returns always the default validator which is UTF8Type as described above (The ColumnDefinition for given column name c is always null) In UTF8Type there is a check for if (b 127) return false; Anyway, maybe i'm doing something wrong, but i used cql 3.0 for table creation. I assigned data types to all columns, but i can not set values for a composite column because the default validation class is used. I think the schema should know the correct validator even for composite columns. The usage of the default validation class does not make sense. Best Regards Bert Passek -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4434) add COPY TO
Jonathan Ellis created CASSANDRA-4434: - Summary: add COPY TO Key: CASSANDRA-4434 URL: https://issues.apache.org/jira/browse/CASSANDRA-4434 Project: Cassandra Issue Type: New Feature Reporter: Jonathan Ellis Assignee: paul cannon Fix For: 1.1.3 CASSANDRA-4012 added COPY FROM; this is a ticket to add the inverse. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4330) cqlsh's desc cluster needs to return the schema agreement information
[ https://issues.apache.org/jira/browse/CASSANDRA-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon resolved CASSANDRA-4330. Resolution: Won't Fix Turns out this is not of much use in 1.1, post schema renaissance, and the information is no longer in the system.Schema table (since the system.schema_* tables are now canonical), so we can't do it via plain CQL. Cqlsh does still use thrift for certain things, but I'd like to move toward eliminating those, rather than adding to it just for 1.0 when cassandra-cli can meet the need acceptably. http://www.datastax.com/dev/blog/the-schema-management-renaissance has good explanations of the changes. cqlsh's desc cluster needs to return the schema agreement information - Key: CASSANDRA-4330 URL: https://issues.apache.org/jira/browse/CASSANDRA-4330 Project: Cassandra Issue Type: Improvement Reporter: Jeremy Hanna Assignee: paul cannon Priority: Minor Labels: cli, cqlsh describe cluster in the cassandra cli is very useful to determine whether the schema for the cluster is in complete agreement among the nodes. It doesn't appear that the cqlsh analog - desc cluster; - does the same thing. Since that's so useful and since cqlsh is the way forward for new cli type of development, it makes sense to add that in some command in cqlsh. Paul said that it should be trivial but if it's not, it may be worth it to wait until the dedicated cql transport to implement it (while it's still there in cassandra-cli). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: add #3794 to NEWS
Updated Branches: refs/heads/trunk 54a3d5395 - 26aff203b add #3794 to NEWS Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/26aff203 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/26aff203 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/26aff203 Branch: refs/heads/trunk Commit: 26aff203b1a89bde2b12353f0e6e084bc111da02 Parents: 54a3d53 Author: Jonathan Ellis jbel...@apache.org Authored: Wed Jul 11 16:33:45 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Jul 11 16:33:45 2012 -0500 -- NEWS.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/26aff203/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index 11c735d..fd13667 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -41,6 +41,8 @@ Upgrading Features +- Cassandra can now handle concurrent CREATE TABLE schema changes + as well as other updates - rpc_timeout has been split up to allow finer-grained control on timeouts for different operation types
[jira] [Commented] (CASSANDRA-4234) Add tombstone-removal compaction to LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-4234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13412036#comment-13412036 ] Jonathan Ellis commented on CASSANDRA-4234: --- I think we need a synchronized method in LeveledManifest to return a copy of generations[i]. Otherwise {{new ArrayListSSTableReader(manifest.getLevel(i)) }}can race and error out. Nit: would rename canDropTombstone to something like worthDroppingTombstones Add tombstone-removal compaction to LCS --- Key: CASSANDRA-4234 URL: https://issues.apache.org/jira/browse/CASSANDRA-4234 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2 Reporter: Jonathan Ellis Assignee: Yuki Morishita Priority: Minor Labels: compaction Fix For: 1.2 Attachments: 4234.txt CASSANDRA-3442 will recompact sstables with high levels of expired tombstones, but only under SCS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: fix 1.0.x node join to mixed version cluster, other nodes = 1.1 patch by Pavel Yaskevich; reviewed by Jonathan Ellis for CASSANDRA-4195
Updated Branches: refs/heads/cassandra-1.0 84a1d6059 - 51a9fd131 fix 1.0.x node join to mixed version cluster, other nodes = 1.1 patch by Pavel Yaskevich; reviewed by Jonathan Ellis for CASSANDRA-4195 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/51a9fd13 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/51a9fd13 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/51a9fd13 Branch: refs/heads/cassandra-1.0 Commit: 51a9fd131a815bf4d368d89b0961429a1d51a532 Parents: 84a1d60 Author: Pavel Yaskevich xe...@apache.org Authored: Mon Jul 9 23:27:57 2012 +0300 Committer: Pavel Yaskevich xe...@apache.org Committed: Thu Jul 12 00:57:18 2012 +0300 -- CHANGES.txt|1 + .../apache/cassandra/service/MigrationManager.java | 30 +-- 2 files changed, 19 insertions(+), 12 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/51a9fd13/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index c752244..d3cca6c 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -9,6 +9,7 @@ sstables, such as when convertinb back from LCS (CASSANDRA-4287) * Oversize integer in CQL throws NumberFormatException (CASSANDRA-4291) * Set gc_grace on index CF to 0 (CASSANDRA-4314) + * fix 1.0.x node join to mixed version cluster, other nodes = 1.1 (CASSANDRA-4195) 1.0.10 http://git-wip-us.apache.org/repos/asf/cassandra/blob/51a9fd13/src/java/org/apache/cassandra/service/MigrationManager.java -- diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java b/src/java/org/apache/cassandra/service/MigrationManager.java index f9e5c33..7adbfea 100644 --- a/src/java/org/apache/cassandra/service/MigrationManager.java +++ b/src/java/org/apache/cassandra/service/MigrationManager.java @@ -56,32 +56,29 @@ public class MigrationManager implements IEndpointStateChangeSubscriber private static volatile UUID highestKnown; -public void onJoin(InetAddress endpoint, EndpointState epState) { +public void onJoin(InetAddress endpoint, EndpointState epState) +{ VersionedValue value = epState.getApplicationState(ApplicationState.SCHEMA); + if (value != null) -{ -UUID theirVersion = UUID.fromString(value.value); -rectify(theirVersion, endpoint); -} +rectify(UUID.fromString(value.value), endpoint); } public void onChange(InetAddress endpoint, ApplicationState state, VersionedValue value) { if (state != ApplicationState.SCHEMA) return; -UUID theirVersion = UUID.fromString(value.value); -rectify(theirVersion, endpoint); + +rectify(UUID.fromString(value.value), endpoint); } /** gets called after a this node joins a cluster */ public void onAlive(InetAddress endpoint, EndpointState state) { VersionedValue value = state.getApplicationState(ApplicationState.SCHEMA); + if (value != null) -{ -UUID theirVersion = UUID.fromString(value.value); -rectify(theirVersion, endpoint); -} +rectify(UUID.fromString(value.value), endpoint); } public void onDead(InetAddress endpoint, EndpointState state) { } @@ -89,13 +86,22 @@ public class MigrationManager implements IEndpointStateChangeSubscriber public void onRestart(InetAddress endpoint, EndpointState state) { } public void onRemove(InetAddress endpoint) { } - + /** * will either push or pull an updating depending on who is behind. * fat clients should never push their schemas (since they have no local storage). */ public static void rectify(UUID theirVersion, InetAddress endpoint) { +if (theirVersion.version() != 1) +{ +logger.warn(Can't merge remove schema because node operates in the mixed version cluster + +(Please upgrade all nodes to = 1.1 to be able to perform schema migrations).); + +highestKnown = Schema.instance.getVersion(); +return; +} + updateHighestKnown(theirVersion); UUID myVersion = Schema.instance.getVersion(); if (theirVersion.timestamp() myVersion.timestamp()
[1/2] git commit: merge from 1.0
Updated Branches: refs/heads/cassandra-1.1 3e4858271 - 97620fef3 merge from 1.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/97620fef Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/97620fef Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/97620fef Branch: refs/heads/cassandra-1.1 Commit: 97620fef3fcf208d9044a95cc8ffe86ccb1e4556 Parents: 3e48582 51a9fd1 Author: Pavel Yaskevich xe...@apache.org Authored: Thu Jul 12 01:04:12 2012 +0300 Committer: Pavel Yaskevich xe...@apache.org Committed: Thu Jul 12 01:04:12 2012 +0300 -- CHANGES.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/97620fef/CHANGES.txt -- diff --cc CHANGES.txt index cb85459,d3cca6c..01a3af1 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,139 -1,6 +1,140 @@@ -1.0.11 +1.1.3 + * update default commitlog segment size to 32MB and total commitlog + size to 32/1024 MB for 32/64 bit JVMs, respectively (CASSANDRA-4422) + * avoid using global partitioner to estimate ranges in index sstables + (CASSANDRA-4403) + * restore pre-CASSANDRA-3862 approach to removing expired tombstones + from row cache during compaction (CASSANDRA-4364) + * (stress) support for CQL prepared statements (CASSANDRA-3633) + * Correctly catch exception when Snappy cannot be loaded (CASSANDRA-4400) + * (cql3) Support ORDER BY when IN condition is given in WHERE clause (CASSANDRA-4327) + * (cql3) delete component_index column on DROP TABLE call (CASSANDRA-4420) + * change nanoTime() to currentTimeInMillis() in schema related code (CASSANDRA-4432) +Merged from 1.0: * allow dropping columns shadowed by not-yet-expired supercolumn or row tombstones in PrecompactedRow (CASSANDRA-4396) ++ * fix 1.0.x node join to mixed version cluster, other nodes = 1.1 (CASSANDRA-4195) + + +1.1.2 + * Fix cleanup not deleting index entries (CASSANDRA-4379) + * Use correct partitioner when saving + loading caches (CASSANDRA-4331) + * Check schema before trying to export sstable (CASSANDRA-2760) + * Raise a meaningful exception instead of NPE when PFS encounters + an unconfigured node + no default (CASSANDRA-4349) + * fix bug in sstable blacklisting with LCS (CASSANDRA-4343) + * LCS no longer promotes tiny sstables out of L0 (CASSANDRA-4341) + * skip tombstones during hint replay (CASSANDRA-4320) + * fix NPE in compactionstats (CASSANDRA-4318) + * enforce 1m min keycache for auto (CASSANDRA-4306) + * Have DeletedColumn.isMFD always return true (CASSANDRA-4307) + * (cql3) exeption message for ORDER BY constraints said primary filter can be +an IN clause, which is misleading (CASSANDRA-4319) + * (cql3) Reject (not yet supported) creation of 2ndardy indexes on tables with + composite primary keys (CASSANDRA-4328) + * Set JVM stack size to 160k for java 7 (CASSANDRA-4275) + * cqlsh: add COPY command to load data from CSV flat files (CASSANDRA-4012) + * CFMetaData.fromThrift to throw ConfigurationException upon error (CASSANDRA-4353) + * Use CF comparator to sort indexed columns in SecondaryIndexManager + (CASSANDRA-4365) + * add strategy_options to the KSMetaData.toString() output (CASSANDRA-4248) + * (cql3) fix range queries containing unqueried results (CASSANDRA-4372) + * (cql3) allow updating column_alias types (CASSANDRA-4041) + * (cql3) Fix deletion bug (CASSANDRA-4193) + * Fix computation of overlapping sstable for leveled compaction (CASSANDRA-4321) + * Improve scrub and allow to run it offline (CASSANDRA-4321) + * Fix assertionError in StorageService.bulkLoad (CASSANDRA-4368) + * (cqlsh) add option to authenticate to a keyspace at startup (CASSANDRA-4108) + * (cqlsh) fix ASSUME functionality (CASSANDRA-4352) + * Fix ColumnFamilyRecordReader to not return progress 100% (CASSANDRA-3942) +Merged from 1.0: + * Set gc_grace on index CF to 0 (CASSANDRA-4314) + + +1.1.1 + * allow larger cache capacities than 2GB (CASSANDRA-4150) + * add getsstables command to nodetool (CASSANDRA-4199) + * apply parent CF compaction settings to secondary index CFs (CASSANDRA-4280) + * preserve commitlog size cap when recycling segments at startup + (CASSANDRA-4201) + * (Hadoop) fix split generation regression (CASSANDRA-4259) + * ignore min/max compactions settings in LCS, while preserving + behavior that min=max=0 disables autocompaction (CASSANDRA-4233) + * log number of rows read from saved cache (CASSANDRA-4249) + * calculate exact size required for cleanup operations (CASSANDRA-1404) + * avoid blocking additional writes during flush when the commitlog + gets behind temporarily (CASSANDRA-1991) + * enable caching on index CFs based on data CF
[2/2] git commit: fix 1.0.x node join to mixed version cluster, other nodes = 1.1 patch by Pavel Yaskevich; reviewed by Jonathan Ellis for CASSANDRA-4195
fix 1.0.x node join to mixed version cluster, other nodes = 1.1 patch by Pavel Yaskevich; reviewed by Jonathan Ellis for CASSANDRA-4195 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/51a9fd13 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/51a9fd13 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/51a9fd13 Branch: refs/heads/cassandra-1.1 Commit: 51a9fd131a815bf4d368d89b0961429a1d51a532 Parents: 84a1d60 Author: Pavel Yaskevich xe...@apache.org Authored: Mon Jul 9 23:27:57 2012 +0300 Committer: Pavel Yaskevich xe...@apache.org Committed: Thu Jul 12 00:57:18 2012 +0300 -- CHANGES.txt|1 + .../apache/cassandra/service/MigrationManager.java | 30 +-- 2 files changed, 19 insertions(+), 12 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/51a9fd13/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index c752244..d3cca6c 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -9,6 +9,7 @@ sstables, such as when convertinb back from LCS (CASSANDRA-4287) * Oversize integer in CQL throws NumberFormatException (CASSANDRA-4291) * Set gc_grace on index CF to 0 (CASSANDRA-4314) + * fix 1.0.x node join to mixed version cluster, other nodes = 1.1 (CASSANDRA-4195) 1.0.10 http://git-wip-us.apache.org/repos/asf/cassandra/blob/51a9fd13/src/java/org/apache/cassandra/service/MigrationManager.java -- diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java b/src/java/org/apache/cassandra/service/MigrationManager.java index f9e5c33..7adbfea 100644 --- a/src/java/org/apache/cassandra/service/MigrationManager.java +++ b/src/java/org/apache/cassandra/service/MigrationManager.java @@ -56,32 +56,29 @@ public class MigrationManager implements IEndpointStateChangeSubscriber private static volatile UUID highestKnown; -public void onJoin(InetAddress endpoint, EndpointState epState) { +public void onJoin(InetAddress endpoint, EndpointState epState) +{ VersionedValue value = epState.getApplicationState(ApplicationState.SCHEMA); + if (value != null) -{ -UUID theirVersion = UUID.fromString(value.value); -rectify(theirVersion, endpoint); -} +rectify(UUID.fromString(value.value), endpoint); } public void onChange(InetAddress endpoint, ApplicationState state, VersionedValue value) { if (state != ApplicationState.SCHEMA) return; -UUID theirVersion = UUID.fromString(value.value); -rectify(theirVersion, endpoint); + +rectify(UUID.fromString(value.value), endpoint); } /** gets called after a this node joins a cluster */ public void onAlive(InetAddress endpoint, EndpointState state) { VersionedValue value = state.getApplicationState(ApplicationState.SCHEMA); + if (value != null) -{ -UUID theirVersion = UUID.fromString(value.value); -rectify(theirVersion, endpoint); -} +rectify(UUID.fromString(value.value), endpoint); } public void onDead(InetAddress endpoint, EndpointState state) { } @@ -89,13 +86,22 @@ public class MigrationManager implements IEndpointStateChangeSubscriber public void onRestart(InetAddress endpoint, EndpointState state) { } public void onRemove(InetAddress endpoint) { } - + /** * will either push or pull an updating depending on who is behind. * fat clients should never push their schemas (since they have no local storage). */ public static void rectify(UUID theirVersion, InetAddress endpoint) { +if (theirVersion.version() != 1) +{ +logger.warn(Can't merge remove schema because node operates in the mixed version cluster + +(Please upgrade all nodes to = 1.1 to be able to perform schema migrations).); + +highestKnown = Schema.instance.getVersion(); +return; +} + updateHighestKnown(theirVersion); UUID myVersion = Schema.instance.getVersion(); if (theirVersion.timestamp() myVersion.timestamp()
[3/3] git commit: fix 1.0.x node join to mixed version cluster, other nodes = 1.1 patch by Pavel Yaskevich; reviewed by Jonathan Ellis for CASSANDRA-4195
fix 1.0.x node join to mixed version cluster, other nodes = 1.1 patch by Pavel Yaskevich; reviewed by Jonathan Ellis for CASSANDRA-4195 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/51a9fd13 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/51a9fd13 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/51a9fd13 Branch: refs/heads/trunk Commit: 51a9fd131a815bf4d368d89b0961429a1d51a532 Parents: 84a1d60 Author: Pavel Yaskevich xe...@apache.org Authored: Mon Jul 9 23:27:57 2012 +0300 Committer: Pavel Yaskevich xe...@apache.org Committed: Thu Jul 12 00:57:18 2012 +0300 -- CHANGES.txt|1 + .../apache/cassandra/service/MigrationManager.java | 30 +-- 2 files changed, 19 insertions(+), 12 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/51a9fd13/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index c752244..d3cca6c 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -9,6 +9,7 @@ sstables, such as when convertinb back from LCS (CASSANDRA-4287) * Oversize integer in CQL throws NumberFormatException (CASSANDRA-4291) * Set gc_grace on index CF to 0 (CASSANDRA-4314) + * fix 1.0.x node join to mixed version cluster, other nodes = 1.1 (CASSANDRA-4195) 1.0.10 http://git-wip-us.apache.org/repos/asf/cassandra/blob/51a9fd13/src/java/org/apache/cassandra/service/MigrationManager.java -- diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java b/src/java/org/apache/cassandra/service/MigrationManager.java index f9e5c33..7adbfea 100644 --- a/src/java/org/apache/cassandra/service/MigrationManager.java +++ b/src/java/org/apache/cassandra/service/MigrationManager.java @@ -56,32 +56,29 @@ public class MigrationManager implements IEndpointStateChangeSubscriber private static volatile UUID highestKnown; -public void onJoin(InetAddress endpoint, EndpointState epState) { +public void onJoin(InetAddress endpoint, EndpointState epState) +{ VersionedValue value = epState.getApplicationState(ApplicationState.SCHEMA); + if (value != null) -{ -UUID theirVersion = UUID.fromString(value.value); -rectify(theirVersion, endpoint); -} +rectify(UUID.fromString(value.value), endpoint); } public void onChange(InetAddress endpoint, ApplicationState state, VersionedValue value) { if (state != ApplicationState.SCHEMA) return; -UUID theirVersion = UUID.fromString(value.value); -rectify(theirVersion, endpoint); + +rectify(UUID.fromString(value.value), endpoint); } /** gets called after a this node joins a cluster */ public void onAlive(InetAddress endpoint, EndpointState state) { VersionedValue value = state.getApplicationState(ApplicationState.SCHEMA); + if (value != null) -{ -UUID theirVersion = UUID.fromString(value.value); -rectify(theirVersion, endpoint); -} +rectify(UUID.fromString(value.value), endpoint); } public void onDead(InetAddress endpoint, EndpointState state) { } @@ -89,13 +86,22 @@ public class MigrationManager implements IEndpointStateChangeSubscriber public void onRestart(InetAddress endpoint, EndpointState state) { } public void onRemove(InetAddress endpoint) { } - + /** * will either push or pull an updating depending on who is behind. * fat clients should never push their schemas (since they have no local storage). */ public static void rectify(UUID theirVersion, InetAddress endpoint) { +if (theirVersion.version() != 1) +{ +logger.warn(Can't merge remove schema because node operates in the mixed version cluster + +(Please upgrade all nodes to = 1.1 to be able to perform schema migrations).); + +highestKnown = Schema.instance.getVersion(); +return; +} + updateHighestKnown(theirVersion); UUID myVersion = Schema.instance.getVersion(); if (theirVersion.timestamp() myVersion.timestamp()
[2/3] git commit: merge from 1.0
merge from 1.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/97620fef Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/97620fef Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/97620fef Branch: refs/heads/trunk Commit: 97620fef3fcf208d9044a95cc8ffe86ccb1e4556 Parents: 3e48582 51a9fd1 Author: Pavel Yaskevich xe...@apache.org Authored: Thu Jul 12 01:04:12 2012 +0300 Committer: Pavel Yaskevich xe...@apache.org Committed: Thu Jul 12 01:04:12 2012 +0300 -- CHANGES.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/97620fef/CHANGES.txt -- diff --cc CHANGES.txt index cb85459,d3cca6c..01a3af1 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,139 -1,6 +1,140 @@@ -1.0.11 +1.1.3 + * update default commitlog segment size to 32MB and total commitlog + size to 32/1024 MB for 32/64 bit JVMs, respectively (CASSANDRA-4422) + * avoid using global partitioner to estimate ranges in index sstables + (CASSANDRA-4403) + * restore pre-CASSANDRA-3862 approach to removing expired tombstones + from row cache during compaction (CASSANDRA-4364) + * (stress) support for CQL prepared statements (CASSANDRA-3633) + * Correctly catch exception when Snappy cannot be loaded (CASSANDRA-4400) + * (cql3) Support ORDER BY when IN condition is given in WHERE clause (CASSANDRA-4327) + * (cql3) delete component_index column on DROP TABLE call (CASSANDRA-4420) + * change nanoTime() to currentTimeInMillis() in schema related code (CASSANDRA-4432) +Merged from 1.0: * allow dropping columns shadowed by not-yet-expired supercolumn or row tombstones in PrecompactedRow (CASSANDRA-4396) ++ * fix 1.0.x node join to mixed version cluster, other nodes = 1.1 (CASSANDRA-4195) + + +1.1.2 + * Fix cleanup not deleting index entries (CASSANDRA-4379) + * Use correct partitioner when saving + loading caches (CASSANDRA-4331) + * Check schema before trying to export sstable (CASSANDRA-2760) + * Raise a meaningful exception instead of NPE when PFS encounters + an unconfigured node + no default (CASSANDRA-4349) + * fix bug in sstable blacklisting with LCS (CASSANDRA-4343) + * LCS no longer promotes tiny sstables out of L0 (CASSANDRA-4341) + * skip tombstones during hint replay (CASSANDRA-4320) + * fix NPE in compactionstats (CASSANDRA-4318) + * enforce 1m min keycache for auto (CASSANDRA-4306) + * Have DeletedColumn.isMFD always return true (CASSANDRA-4307) + * (cql3) exeption message for ORDER BY constraints said primary filter can be +an IN clause, which is misleading (CASSANDRA-4319) + * (cql3) Reject (not yet supported) creation of 2ndardy indexes on tables with + composite primary keys (CASSANDRA-4328) + * Set JVM stack size to 160k for java 7 (CASSANDRA-4275) + * cqlsh: add COPY command to load data from CSV flat files (CASSANDRA-4012) + * CFMetaData.fromThrift to throw ConfigurationException upon error (CASSANDRA-4353) + * Use CF comparator to sort indexed columns in SecondaryIndexManager + (CASSANDRA-4365) + * add strategy_options to the KSMetaData.toString() output (CASSANDRA-4248) + * (cql3) fix range queries containing unqueried results (CASSANDRA-4372) + * (cql3) allow updating column_alias types (CASSANDRA-4041) + * (cql3) Fix deletion bug (CASSANDRA-4193) + * Fix computation of overlapping sstable for leveled compaction (CASSANDRA-4321) + * Improve scrub and allow to run it offline (CASSANDRA-4321) + * Fix assertionError in StorageService.bulkLoad (CASSANDRA-4368) + * (cqlsh) add option to authenticate to a keyspace at startup (CASSANDRA-4108) + * (cqlsh) fix ASSUME functionality (CASSANDRA-4352) + * Fix ColumnFamilyRecordReader to not return progress 100% (CASSANDRA-3942) +Merged from 1.0: + * Set gc_grace on index CF to 0 (CASSANDRA-4314) + + +1.1.1 + * allow larger cache capacities than 2GB (CASSANDRA-4150) + * add getsstables command to nodetool (CASSANDRA-4199) + * apply parent CF compaction settings to secondary index CFs (CASSANDRA-4280) + * preserve commitlog size cap when recycling segments at startup + (CASSANDRA-4201) + * (Hadoop) fix split generation regression (CASSANDRA-4259) + * ignore min/max compactions settings in LCS, while preserving + behavior that min=max=0 disables autocompaction (CASSANDRA-4233) + * log number of rows read from saved cache (CASSANDRA-4249) + * calculate exact size required for cleanup operations (CASSANDRA-1404) + * avoid blocking additional writes during flush when the commitlog + gets behind temporarily (CASSANDRA-1991) + * enable caching on index CFs based on data CF cache setting (CASSANDRA-4197) + * warn on invalid replication strategy
[jira] [Updated] (CASSANDRA-3709) Add a token generator to standard tools
[ https://issues.apache.org/jira/browse/CASSANDRA-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-3709: --- Attachment: (was: 3709.patch.txt) Add a token generator to standard tools --- Key: CASSANDRA-3709 URL: https://issues.apache.org/jira/browse/CASSANDRA-3709 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: paul cannon Priority: Minor Fix For: 1.1.3 We recommend spacing nodes in a new cluster evenly around the ring; we should provide a tool to generate appropriate tokens for a cluster of size X. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3709) Add a token generator to standard tools
[ https://issues.apache.org/jira/browse/CASSANDRA-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-3709: --- Attachment: 3709.patch.txt New version prefers to optimize for NTS, but keeps the mode for ONTS behind an option. My 3709 branch is updated at github; new tag is pending/3709-2. Add a token generator to standard tools --- Key: CASSANDRA-3709 URL: https://issues.apache.org/jira/browse/CASSANDRA-3709 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: paul cannon Priority: Minor Fix For: 1.1.3 Attachments: 3709.patch.txt We recommend spacing nodes in a new cluster evenly around the ring; we should provide a tool to generate appropriate tokens for a cluster of size X. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4292) Per-disk I/O queues
[ https://issues.apache.org/jira/browse/CASSANDRA-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-4292: -- Attachment: 4292.txt Attaching patch to get initial feedback. The basic idea is to create ThreadPoolExecutor per disk, and when submitting flush task, it is bound to one of executor based on disk space. In this version, I set thread pool size to 1. This is fine when your data directories are all on spinning disks, but for SSD, you might want to increase this value. In order to set pool size per disk, we need to create new config option. Current global _memtable_flush_writers_ option is no longer used in this patch. Per-disk I/O queues --- Key: CASSANDRA-4292 URL: https://issues.apache.org/jira/browse/CASSANDRA-4292 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Yuki Morishita Fix For: 1.2 Attachments: 4292.txt As noted in CASSANDRA-809, we have a certain amount of flush (and compaction) threads, which mix and match disk volumes indiscriminately. It may be worth creating a tight thread - disk affinity, to prevent unnecessary conflict at that level. OTOH as SSDs become more prevalent this becomes a non-issue. Unclear how much pain this actually causes in practice in the meantime. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4414) Ship the exact cause for timeout and unavailable exception back to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13412278#comment-13412278 ] Jonathan Ellis commented on CASSANDRA-4414: --- bq. I do think we should break this apart into a separate exception I still would like to do this in an ideal world but I think our hands might be tied by the client community... unless we're willing to break everyone who doesn't add IPE, the optional field is a better approach. Ship the exact cause for timeout and unavailable exception back to the client -- Key: CASSANDRA-4414 URL: https://issues.apache.org/jira/browse/CASSANDRA-4414 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Fix For: 1.2 Currently when a client gets a timeout exception, it doesn't know what happened. But sever side we usually know a little more than that. For example, for 99% of the timeouts at CL ONE, we will have some replica that have acknowlege. I think it could be useful to send that information to the client with the exception. That could help with monitoring, post-mortem analysis and debugging. Unavailable exceptions could also ship which nodes were alive and which ones where not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3687) Local range scans are not run on the read stage
[ https://issues.apache.org/jira/browse/CASSANDRA-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13412493#comment-13412493 ] Vijay commented on CASSANDRA-3687: -- +1 Local range scans are not run on the read stage --- Key: CASSANDRA-3687 URL: https://issues.apache.org/jira/browse/CASSANDRA-3687 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.2 Running directly on the client request/StorageProxy thread means we're now allowing one range scan per thrift thread instead of one per read stage thread [which may be more, or less, depending on thrift server mode], and it bypasses the drop hopeless requests overcapacity protection built in there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira