[jira] [Updated] (CASSANDRA-4183) Fix dependency versions in generated pos
[ https://issues.apache.org/jira/browse/CASSANDRA-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated CASSANDRA-4183: Attachment: CASSANDRA-4183.diff Fix dependency versions in generated pos Key: CASSANDRA-4183 URL: https://issues.apache.org/jira/browse/CASSANDRA-4183 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 1.1.0 Reporter: Stephen Connolly Fix For: 1.1.1 Attachments: CASSANDRA-4183.diff Some of the versions of dependencies have fallen out of sync -- 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-4183) Fix dependency versions in generated pos
Stephen Connolly created CASSANDRA-4183: --- Summary: Fix dependency versions in generated pos Key: CASSANDRA-4183 URL: https://issues.apache.org/jira/browse/CASSANDRA-4183 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 1.1.0 Reporter: Stephen Connolly Fix For: 1.1.1 Attachments: CASSANDRA-4183.diff Some of the versions of dependencies have fallen out of sync -- 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-4183) Fix dependency versions in generated pos
[ https://issues.apache.org/jira/browse/CASSANDRA-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261394#comment-13261394 ] Stephen Connolly commented on CASSANDRA-4183: - Patch should also be applied to trunk Fix dependency versions in generated pos Key: CASSANDRA-4183 URL: https://issues.apache.org/jira/browse/CASSANDRA-4183 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 1.1.0 Reporter: Stephen Connolly Fix For: 1.1.1 Attachments: CASSANDRA-4183.diff Some of the versions of dependencies have fallen out of sync -- 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-3758) parallel compaction hang (on large rows?)
[ https://issues.apache.org/jira/browse/CASSANDRA-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261597#comment-13261597 ] ruslan.usifov commented on CASSANDRA-3758: -- We use 0.8.10. And nodetool -h localhost compactionstats pending tasks: 1 Dissapear only after cassandra restart. This happens only ones, without no any warning or Exceptions in logs parallel compaction hang (on large rows?) - Key: CASSANDRA-3758 URL: https://issues.apache.org/jira/browse/CASSANDRA-3758 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jackson Chung Priority: Minor Labels: compaction, datastax_qa Fix For: 1.0.10 Attachments: 0001-Fix-totalBytes-count-for-ParallelCompactionIterable.txt, cassandra.log.zip it is observed that: nodetool -h 127.0.0.1 -p 8080 compactionstats pending tasks: 1 compaction type keyspace column family bytes compacted bytes total progress Compaction SyncCoreComputedContactNetworks 119739938 0 n/a and that is not moving (ie the bytes compacted never increase, the bytes total stay 0). this is probably going to be difficult to reproduce, as the problem is observed when compacting 15 large sstables (total ~300G). attaching the thread dumps (along with logs), when such happen. -- 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-4184) Make identifier and value grammar for CQL3 stricter
Sylvain Lebresne created CASSANDRA-4184:
---
Summary: Make identifier and value grammar for CQL3 stricter
Key: CASSANDRA-4184
URL: https://issues.apache.org/jira/browse/CASSANDRA-4184
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.1.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Fix For: 1.1.1
The current grammar for CQL3 allows:
# uuid and integer constants as identifiers
# identifier as value (aka term in the grammar)
I think both of those should be removed.
For 1, mostly because this feels useless and slightly complicates the grammar
which is annoying for the documentation of CQL3 for instance (note that this
doesn't mean forbidding integer or uuid as identifier, but means they have to
be double-quoted when used as such).
For 2, I think that allowing identifier as value is actually misleading,
typically if you write things like {{SELECT foo WHERE foo=foo}}. It suggests we
support JOIN when we do not.
Also, if both are done, then one will always be able to distinguish between
identifier and value even without any context, which is a nice property.
--
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-4184) Make identifier and value grammar for CQL3 stricter
[
https://issues.apache.org/jira/browse/CASSANDRA-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4184:
Attachment: 0002-Disallow-identifier-as-value.txt
0001-Disallow-integer-and-uuid-constants-as-identifier.txt
Make identifier and value grammar for CQL3 stricter
---
Key: CASSANDRA-4184
URL: https://issues.apache.org/jira/browse/CASSANDRA-4184
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.1.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.1.1
Attachments:
0001-Disallow-integer-and-uuid-constants-as-identifier.txt,
0002-Disallow-identifier-as-value.txt
The current grammar for CQL3 allows:
# uuid and integer constants as identifiers
# identifier as value (aka term in the grammar)
I think both of those should be removed.
For 1, mostly because this feels useless and slightly complicates the grammar
which is annoying for the documentation of CQL3 for instance (note that this
doesn't mean forbidding integer or uuid as identifier, but means they have to
be double-quoted when used as such).
For 2, I think that allowing identifier as value is actually misleading,
typically if you write things like {{SELECT foo WHERE foo=foo}}. It suggests
we support JOIN when we do not.
Also, if both are done, then one will always be able to distinguish between
identifier and value even without any context, which is a nice property.
--
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-4185) Minor CQL3 fixes
Sylvain Lebresne created CASSANDRA-4185: --- Summary: Minor CQL3 fixes Key: CASSANDRA-4185 URL: https://issues.apache.org/jira/browse/CASSANDRA-4185 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.1.1 The goal of this ticket is to be the home for a number of minor fixes/improvements in CQL3 that I didn't felt warranted a ticket each. It includes 4 patches: * The first one fixes the grammar for float constants, so as to not recognize 3.-3, but to actually allow 3. (i.e, with radix point but with the fractional part left blank) * The second one correctly detect the (invalid) case where a table is created with COMPACT STORAGE but without any 'clustering keys'. * The third one fixes COUNT, first by making sure both COUNT(*) and COUNT(1) are correctly recognized and also by processing the internal row before counting, are there isn't a 1-to-1 correspondence between internal rows and CQL rows in CQL3. The grammar change in this patch actually rely on CASSANDRA-4184 * The fourth and last patch disallows the counter type for keys (i.e. any column part of the PRIMARY KEY) as it is completely non-sensical and will only led to confusion. -- 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-4185) Minor CQL3 fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4185: Attachment: 0004-Disallow-counters-for-PRIMARY-KEY-part.txt 0003-Fix-COUNT-in-select.txt 0002-Fix-compact-storage-validation.txt 0001-Fix-float-parsing.txt Minor CQL3 fixes Key: CASSANDRA-4185 URL: https://issues.apache.org/jira/browse/CASSANDRA-4185 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Fix For: 1.1.1 Attachments: 0001-Fix-float-parsing.txt, 0002-Fix-compact-storage-validation.txt, 0003-Fix-COUNT-in-select.txt, 0004-Disallow-counters-for-PRIMARY-KEY-part.txt The goal of this ticket is to be the home for a number of minor fixes/improvements in CQL3 that I didn't felt warranted a ticket each. It includes 4 patches: * The first one fixes the grammar for float constants, so as to not recognize 3.-3, but to actually allow 3. (i.e, with radix point but with the fractional part left blank) * The second one correctly detect the (invalid) case where a table is created with COMPACT STORAGE but without any 'clustering keys'. * The third one fixes COUNT, first by making sure both COUNT(*) and COUNT(1) are correctly recognized and also by processing the internal row before counting, are there isn't a 1-to-1 correspondence between internal rows and CQL rows in CQL3. The grammar change in this patch actually rely on CASSANDRA-4184 * The fourth and last patch disallows the counter type for keys (i.e. any column part of the PRIMARY KEY) as it is completely non-sensical and will only led to confusion. -- 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-4185) Minor CQL3 fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4185: Attachment: (was: 0004-Disallow-counters-for-PRIMARY-KEY-part.txt) Minor CQL3 fixes Key: CASSANDRA-4185 URL: https://issues.apache.org/jira/browse/CASSANDRA-4185 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Fix For: 1.1.1 Attachments: 0001-Fix-float-parsing.txt, 0002-Fix-compact-storage-validation.txt, 0003-Fix-COUNT-in-select.txt, 0004-Disallow-counters-for-PRIMARY-KEY-part-v2.txt The goal of this ticket is to be the home for a number of minor fixes/improvements in CQL3 that I didn't felt warranted a ticket each. It includes 4 patches: * The first one fixes the grammar for float constants, so as to not recognize 3.-3, but to actually allow 3. (i.e, with radix point but with the fractional part left blank) * The second one correctly detect the (invalid) case where a table is created with COMPACT STORAGE but without any 'clustering keys'. * The third one fixes COUNT, first by making sure both COUNT(*) and COUNT(1) are correctly recognized and also by processing the internal row before counting, are there isn't a 1-to-1 correspondence between internal rows and CQL rows in CQL3. The grammar change in this patch actually rely on CASSANDRA-4184 * The fourth and last patch disallows the counter type for keys (i.e. any column part of the PRIMARY KEY) as it is completely non-sensical and will only led to confusion. -- 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-4185) Minor CQL3 fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4185: Attachment: 0004-Disallow-counters-for-PRIMARY-KEY-part-v2.txt Realized the last patch was missing some parts. v2 attached with those missing parts. Minor CQL3 fixes Key: CASSANDRA-4185 URL: https://issues.apache.org/jira/browse/CASSANDRA-4185 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Fix For: 1.1.1 Attachments: 0001-Fix-float-parsing.txt, 0002-Fix-compact-storage-validation.txt, 0003-Fix-COUNT-in-select.txt, 0004-Disallow-counters-for-PRIMARY-KEY-part-v2.txt The goal of this ticket is to be the home for a number of minor fixes/improvements in CQL3 that I didn't felt warranted a ticket each. It includes 4 patches: * The first one fixes the grammar for float constants, so as to not recognize 3.-3, but to actually allow 3. (i.e, with radix point but with the fractional part left blank) * The second one correctly detect the (invalid) case where a table is created with COMPACT STORAGE but without any 'clustering keys'. * The third one fixes COUNT, first by making sure both COUNT(*) and COUNT(1) are correctly recognized and also by processing the internal row before counting, are there isn't a 1-to-1 correspondence between internal rows and CQL rows in CQL3. The grammar change in this patch actually rely on CASSANDRA-4184 * The fourth and last patch disallows the counter type for keys (i.e. any column part of the PRIMARY KEY) as it is completely non-sensical and will only led to confusion. -- 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-4184) Make identifier and value grammar for CQL3 stricter
[
https://issues.apache.org/jira/browse/CASSANDRA-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261682#comment-13261682
]
Eric Evans commented on CASSANDRA-4184:
---
For what it's worth, allowing IDENT here was done to optimize for user
experience in interactive sessions; To avoid having to quote something if it
could be unambiguously parsed. I believe it was Jonathan that championed this.
I wasn't in favor of it initially (like you, I was trying to simplify the
grammar), but it's grown on me.
Make identifier and value grammar for CQL3 stricter
---
Key: CASSANDRA-4184
URL: https://issues.apache.org/jira/browse/CASSANDRA-4184
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.1.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.1.1
Attachments:
0001-Disallow-integer-and-uuid-constants-as-identifier.txt,
0002-Disallow-identifier-as-value.txt
The current grammar for CQL3 allows:
# uuid and integer constants as identifiers
# identifier as value (aka term in the grammar)
I think both of those should be removed.
For 1, mostly because this feels useless and slightly complicates the grammar
which is annoying for the documentation of CQL3 for instance (note that this
doesn't mean forbidding integer or uuid as identifier, but means they have to
be double-quoted when used as such).
For 2, I think that allowing identifier as value is actually misleading,
typically if you write things like {{SELECT foo WHERE foo=foo}}. It suggests
we support JOIN when we do not.
Also, if both are done, then one will always be able to distinguish between
identifier and value even without any context, which is a nice property.
--
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/7] git commit: Merge branch 'cassandra-1.1' into trunk
Updated Branches: refs/heads/cassandra-1.1 7daa6625a - 58dceaa6a refs/heads/trunk edf9e0e16 - ea117154f 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/ea117154 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ea117154 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ea117154 Branch: refs/heads/trunk Commit: ea117154f15c423e5ee9de2c920b9f69444ac164 Parents: edf9e0e 58dceaa Author: Jonathan Ellis jbel...@apache.org Authored: Wed Apr 25 10:29:31 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Apr 25 10:29:31 2012 -0500 -- CHANGES.txt |1 + NEWS.txt|9 + 2 files changed, 10 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ea117154/CHANGES.txt -- diff --cc CHANGES.txt index a316a49,6a7a67b..00aa405 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,14 -1,5 +1,15 @@@ +1.2-dev + * Track tombstone expiration and compact when tombstone content is + higher than a configurable threshold, default 20% (CASSANDRA-3442) + * update MurmurHash to version 3 (CASSANDRA-2975) + * (CLI) track elapsed time for `delete' operation (CASSANDRA-4060) + * (CLI) jline version is bumped to 1.0 to properly support + 'delete' key function (CASSANDRA-4132) + * Save IndexSummary into new SSTable 'Summary' component (CASSANDRA-2392) + + 1.1.1-dev + * streaming commitlog backup + pitr (CASSANDRA-3690) * avoid generating redundant compaction tasks during streaming (CASSANDRA-4174) * add -cf option to nodetool snapshot, and takeColumnFamilySnapshot to
[3/7] git commit: update CHANGES and NEWS for 3690
update CHANGES and NEWS for 3690 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/58dceaa6 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/58dceaa6 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/58dceaa6 Branch: refs/heads/trunk Commit: 58dceaa6a8ef31db5fc7e7c7afd83891c9cf8d14 Parents: 7daa662 Author: Jonathan Ellis jbel...@apache.org Authored: Wed Apr 25 10:29:20 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Apr 25 10:29:20 2012 -0500 -- CHANGES.txt |1 + NEWS.txt|9 + 2 files changed, 10 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/58dceaa6/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 47f95ce..6a7a67b 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.1.1-dev + * streaming commitlog backup + pitr (CASSANDRA-3690) * avoid generating redundant compaction tasks during streaming (CASSANDRA-4174) * add -cf option to nodetool snapshot, and takeColumnFamilySnapshot to http://git-wip-us.apache.org/repos/asf/cassandra/blob/58dceaa6/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index 1c8344d..89af1ab 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -9,6 +9,15 @@ upgrade, just in case you need to roll back to the previous version. by version X, but the inverse is not necessarily the case.) +1.1.1 += + +Features + +- Continuous commitlog archiving and point-in-time recovery. + See conf/commitlog_archiving.properties + + 1.1 ===
[6/7] git commit: Remove other obsolete NEW entry
Remove other obsolete NEW entry Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5276e837 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5276e837 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5276e837 Branch: refs/heads/trunk Commit: 5276e8375f602980bda6232085f89c0131ea985b Parents: 706edf9 Author: Sylvain Lebresne sylv...@datastax.com Authored: Fri Apr 20 17:32:13 2012 +0200 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Tue Apr 24 20:21:24 2012 +0200 -- NEWS.txt |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/5276e837/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index 2c5f7b4..4522e03 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -16,9 +16,6 @@ Upgrading - - Compression is enabled by default on newly created ColumnFamilies (and unchanged for ColumnFamilies created prior to upgrading). -- The KsDef.replication_factor field (deprecated since 0.8) has - been removed. Older clients will need to be updated to be able - to continue to created and update keyspaces. - If you are running a multi datacenter setup, you should upgrade to the latest 1.0.x (or 0.8.x) release before upgrading. Versions 0.8.8 and 1.0.3-1.0.5 generate cross-dc forwarding that is incompatible
[4/7] git commit: Fix wide row counter deserialization. Patch by Marco Cova, reviewed by brandonwilliams for CASSANDRA-4181
Fix wide row counter deserialization.
Patch by Marco Cova, reviewed by brandonwilliams for CASSANDRA-4181
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7daa6625
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7daa6625
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7daa6625
Branch: refs/heads/trunk
Commit: 7daa6625a19e7556e0514e7c46efe6dab0b9de14
Parents: 3c4fa12
Author: Brandon Williams brandonwilli...@apache.org
Authored: Tue Apr 24 13:26:01 2012 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Tue Apr 24 13:26:01 2012 -0500
--
.../cassandra/hadoop/ColumnFamilyRecordReader.java |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7daa6625/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
index 9459d5a..f4a2a7b 100644
--- a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
+++ b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
@@ -501,7 +501,8 @@ public class ColumnFamilyRecordReader extends
RecordReaderByteBuffer, SortedMap
if (columns.hasNext())
{
ColumnOrSuperColumn cosc = columns.next();
-ImmutableSortedMapByteBuffer, IColumn map =
ImmutableSortedMap.of(cosc.column.name, unthriftifySimple(cosc.column));
+IColumn column = unthriftify(cosc);
+ImmutableSortedMapByteBuffer, IColumn map =
ImmutableSortedMap.of(column.name(), column);
return Pair.ByteBuffer, SortedMapByteBuffer,
IColumncreate(currentRow.key, map);
}
[2/7] git commit: update CHANGES and NEWS for 3690
update CHANGES and NEWS for 3690 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/58dceaa6 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/58dceaa6 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/58dceaa6 Branch: refs/heads/cassandra-1.1 Commit: 58dceaa6a8ef31db5fc7e7c7afd83891c9cf8d14 Parents: 7daa662 Author: Jonathan Ellis jbel...@apache.org Authored: Wed Apr 25 10:29:20 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Apr 25 10:29:20 2012 -0500 -- CHANGES.txt |1 + NEWS.txt|9 + 2 files changed, 10 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/58dceaa6/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 47f95ce..6a7a67b 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.1.1-dev + * streaming commitlog backup + pitr (CASSANDRA-3690) * avoid generating redundant compaction tasks during streaming (CASSANDRA-4174) * add -cf option to nodetool snapshot, and takeColumnFamilySnapshot to http://git-wip-us.apache.org/repos/asf/cassandra/blob/58dceaa6/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index 1c8344d..89af1ab 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -9,6 +9,15 @@ upgrade, just in case you need to roll back to the previous version. by version X, but the inverse is not necessarily the case.) +1.1.1 += + +Features + +- Continuous commitlog archiving and point-in-time recovery. + See conf/commitlog_archiving.properties + + 1.1 ===
[7/7] git commit: add concurrent schema, cql3, and CFRR wide rows to NEWS. clarify that KeyRange.filter allows Hadoop to take advantage of C* indexes
add concurrent schema, cql3, and CFRR wide rows to NEWS. clarify that KeyRange.filter allows Hadoop to take advantage of C* indexes Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3c4fa12e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3c4fa12e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3c4fa12e Branch: refs/heads/trunk Commit: 3c4fa12e15f26f5ddd5f9f8322dc1495f0c761e0 Parents: 5276e83 Author: Jonathan Ellis jbel...@apache.org Authored: Fri Apr 20 10:59:01 2012 -0500 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Tue Apr 24 20:21:24 2012 +0200 -- NEWS.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3c4fa12e/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index 4522e03..1c8344d 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -81,7 +81,7 @@ Features - Streaming is now multithreaded. - Compactions may now be aborted via JMX or nodetool. - The stress tool is not new in 1.1, but it is newly included in - binary builds now, as well as the source tree. + binary builds as well as the source tree - Hadoop: a new BulkOutputFormat is included which will directly write SSTables locally and then stream them into the cluster. YOU SHOULD USE BulkOutputFormat BY DEFAULT. ColumnFamilyOutputFormat
[5/7] git commit: Remove obsolete line from the NEWS file
Remove obsolete line from the NEWS file Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/706edf94 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/706edf94 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/706edf94 Branch: refs/heads/trunk Commit: 706edf94f809e4def86ea04fc5eb61b71ad699da Parents: 808d7c9 Author: Sylvain Lebresne sylv...@datastax.com Authored: Fri Apr 20 17:30:57 2012 +0200 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Tue Apr 24 20:21:24 2012 +0200 -- NEWS.txt |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/706edf94/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index 8593ee5..2c5f7b4 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -19,9 +19,6 @@ Upgrading - The KsDef.replication_factor field (deprecated since 0.8) has been removed. Older clients will need to be updated to be able to continue to created and update keyspaces. -- The KsDef.replication_factor field (deprecated since 0.8) has - been removed. Older clients will need to be updated to be able - to continue to created and update keyspaces. - If you are running a multi datacenter setup, you should upgrade to the latest 1.0.x (or 0.8.x) release before upgrading. Versions 0.8.8 and 1.0.3-1.0.5 generate cross-dc forwarding that is incompatible
[jira] [Created] (CASSANDRA-4186) CQL3: make some keywords unreserved
Sylvain Lebresne created CASSANDRA-4186:
---
Summary: CQL3: make some keywords unreserved
Key: CASSANDRA-4186
URL: https://issues.apache.org/jira/browse/CASSANDRA-4186
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.1.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.1.1
CQL has quite a few keywords. Currently all of them are reserved, but this is
not always necessary. PostreSQL for instance distinguish between reserved
keywords and non-reserved ones, and allow things like {{key}}, {{timestamp}} or
{{type}} as identifiers. I suggest we do the same as convenience for the user.
--
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-4186) CQL3: make some keywords unreserved
[
https://issues.apache.org/jira/browse/CASSANDRA-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4186:
Attachment: 0001-Add-unreserved-words.txt
Patch attached to have some keywords not reserved. I'll admit I've use the list
of reserved/non-reserver keywords of postgreSQL as inspiration for which to
reserve or not, but I'm open to a few changes if someone has good reason for it.
The patch also adds the list of native types directly in the grammar so as to
only parse those (or a string for custom ones) and to make them case
insensitive. They are not reserved.
CQL3: make some keywords unreserved
---
Key: CASSANDRA-4186
URL: https://issues.apache.org/jira/browse/CASSANDRA-4186
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.1.1
Attachments: 0001-Add-unreserved-words.txt
CQL has quite a few keywords. Currently all of them are reserved, but this is
not always necessary. PostreSQL for instance distinguish between reserved
keywords and non-reserved ones, and allow things like {{key}}, {{timestamp}}
or {{type}} as identifiers. I suggest we do the same as convenience for the
user.
--
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-4184) Make identifier and value grammar for CQL3 stricter
[
https://issues.apache.org/jira/browse/CASSANDRA-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261772#comment-13261772
]
Sylvain Lebresne commented on CASSANDRA-4184:
-
bq. Is the main point of ident is to say this can be a column name?
Yes.
bq. I still do like the idea of saying uuids are a native data type and don't
need quoting, like ints or doubles though.
Sure, I'm not proposing to remove that. They are uuid constants and are
special in the grammar. Currently a value is number | string | uuid |
identifier. I'm proposing to remove identifier. Because, if we allow it and
have a table with columns {{foo}} and {{bar}}, then the behavior of {{SELECT *
WHERE foo=bar}} is *very* unintuitive, as it does not return the records who
have the same value for {{foo}} and {{bar}}, but rather {{bar}} is silently
accepted as an equivalent for {{'bar'}}.
Make identifier and value grammar for CQL3 stricter
---
Key: CASSANDRA-4184
URL: https://issues.apache.org/jira/browse/CASSANDRA-4184
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.1.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.1.1
Attachments:
0001-Disallow-integer-and-uuid-constants-as-identifier.txt,
0002-Disallow-identifier-as-value.txt
The current grammar for CQL3 allows:
# uuid and integer constants as identifiers
# identifier as value (aka term in the grammar)
I think both of those should be removed.
For 1, mostly because this feels useless and slightly complicates the grammar
which is annoying for the documentation of CQL3 for instance (note that this
doesn't mean forbidding integer or uuid as identifier, but means they have to
be double-quoted when used as such).
For 2, I think that allowing identifier as value is actually misleading,
typically if you write things like {{SELECT foo WHERE foo=foo}}. It suggests
we support JOIN when we do not.
Also, if both are done, then one will always be able to distinguish between
identifier and value even without any context, which is a nice property.
--
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
[2/3] git commit: add 3912 to CHANGES, NEWS
add 3912 to CHANGES, NEWS Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/cc68c49f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/cc68c49f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/cc68c49f Branch: refs/heads/trunk Commit: cc68c49f47426dbd89bf869d9b3d10de6e78d2ca Parents: 58dceaa Author: Jonathan Ellis jbel...@apache.org Authored: Wed Apr 25 11:22:19 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Apr 25 11:22:19 2012 -0500 -- CHANGES.txt |1 + NEWS.txt|1 + 2 files changed, 2 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/cc68c49f/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 6a7a67b..ad2e12e 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.1.1-dev + * incremental repair by token range (CASSANDRA-3912) * streaming commitlog backup + pitr (CASSANDRA-3690) * avoid generating redundant compaction tasks during streaming (CASSANDRA-4174) http://git-wip-us.apache.org/repos/asf/cassandra/blob/cc68c49f/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index 89af1ab..8c65101 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -16,6 +16,7 @@ Features - Continuous commitlog archiving and point-in-time recovery. See conf/commitlog_archiving.properties +- Incremental repair by token range, exposed over JMX 1.1
[1/3] git commit: Merge branch 'cassandra-1.1' into trunk
Updated Branches: refs/heads/cassandra-1.1 58dceaa6a - cc68c49f4 refs/heads/trunk ea117154f - a05a5641f 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/a05a5641 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a05a5641 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a05a5641 Branch: refs/heads/trunk Commit: a05a5641fffe0b44c32658843df8acee2765c13d Parents: ea11715 cc68c49 Author: Jonathan Ellis jbel...@apache.org Authored: Wed Apr 25 11:22:25 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Apr 25 11:22:25 2012 -0500 -- CHANGES.txt |1 + NEWS.txt|1 + 2 files changed, 2 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a05a5641/CHANGES.txt -- diff --cc CHANGES.txt index 00aa405,ad2e12e..3d0b64a --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,14 -1,5 +1,15 @@@ +1.2-dev + * Track tombstone expiration and compact when tombstone content is + higher than a configurable threshold, default 20% (CASSANDRA-3442) + * update MurmurHash to version 3 (CASSANDRA-2975) + * (CLI) track elapsed time for `delete' operation (CASSANDRA-4060) + * (CLI) jline version is bumped to 1.0 to properly support + 'delete' key function (CASSANDRA-4132) + * Save IndexSummary into new SSTable 'Summary' component (CASSANDRA-2392) + + 1.1.1-dev + * incremental repair by token range (CASSANDRA-3912) * streaming commitlog backup + pitr (CASSANDRA-3690) * avoid generating redundant compaction tasks during streaming (CASSANDRA-4174)
[3/3] git commit: add 3912 to CHANGES, NEWS
add 3912 to CHANGES, NEWS Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/cc68c49f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/cc68c49f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/cc68c49f Branch: refs/heads/cassandra-1.1 Commit: cc68c49f47426dbd89bf869d9b3d10de6e78d2ca Parents: 58dceaa Author: Jonathan Ellis jbel...@apache.org Authored: Wed Apr 25 11:22:19 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Apr 25 11:22:19 2012 -0500 -- CHANGES.txt |1 + NEWS.txt|1 + 2 files changed, 2 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/cc68c49f/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 6a7a67b..ad2e12e 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.1.1-dev + * incremental repair by token range (CASSANDRA-3912) * streaming commitlog backup + pitr (CASSANDRA-3690) * avoid generating redundant compaction tasks during streaming (CASSANDRA-4174) http://git-wip-us.apache.org/repos/asf/cassandra/blob/cc68c49f/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index 89af1ab..8c65101 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -16,6 +16,7 @@ Features - Continuous commitlog archiving and point-in-time recovery. See conf/commitlog_archiving.properties +- Incremental repair by token range, exposed over JMX 1.1
[jira] [Updated] (CASSANDRA-3912) support incremental repair controlled by external agent
[
https://issues.apache.org/jira/browse/CASSANDRA-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3912:
--
Labels: jmx (was: )
Issue Type: New Feature (was: Improvement)
support incremental repair controlled by external agent
---
Key: CASSANDRA-3912
URL: https://issues.apache.org/jira/browse/CASSANDRA-3912
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Peter Schuller
Assignee: Peter Schuller
Labels: jmx
Fix For: 1.1.1
Attachments: 3912_v2.txt, CASSANDRA-3912-trunk-v1.txt,
CASSANDRA-3912-v2-001-add-nodetool-commands.txt,
CASSANDRA-3912-v2-002-fix-antientropyservice.txt
As a poor man's pre-cursor to CASSANDRA-2699, exposing the ability to repair
small parts of a range is extremely useful because it allows (with external
scripting logic) to slowly repair a node's content over time. Other than
avoiding the bulkyness of complete repairs, it means that you can safely do
repairs even if you absolutely cannot afford e.g. disk spaces spikes (see
CASSANDRA-2699 for what the issues are).
Attaching a patch that exposes a repairincremental command to nodetool,
where you specify a step and the number of total steps. Incrementally
performing a repair in 100 steps, for example, would be done by:
{code}
nodetool repairincremental 0 100
nodetool repairincremental 1 100
...
nodetool repairincremental 99 100
{code}
An external script can be used to keep track of what has been repaired and
when. This should allow (1) allow incremental repair to happen now/soon, and
(2) allow experimentation and evaluation for an implementation of
CASSANDRA-2699 which I still think is a good idea. This patch does nothing to
help the average deployment, but at least makes incremental repair possible
given sufficient effort spent on external scripting.
The big no-no about the patch is that it is entirely specific to
RandomPartitioner and BigIntegerToken. If someone can suggest a way to
implement this command generically using the Range/Token abstractions, I'd be
happy to hear suggestions.
An alternative would be to provide a nodetool command that allows you to
simply specify the specific token ranges on the command line. It makes using
it a bit more difficult, but would mean that it works for any partitioner and
token type.
Unless someone can suggest a better way to do this, I think I'll provide a
patch that does this. I'm still leaning towards supporting the simple step N
out of M form though.
--
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-4184) Make identifier and value grammar for CQL3 stricter
[
https://issues.apache.org/jira/browse/CASSANDRA-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261778#comment-13261778
]
Jonathan Ellis commented on CASSANDRA-4184:
---
+1 from me then. How about you, Eric?
Make identifier and value grammar for CQL3 stricter
---
Key: CASSANDRA-4184
URL: https://issues.apache.org/jira/browse/CASSANDRA-4184
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.1.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.1.1
Attachments:
0001-Disallow-integer-and-uuid-constants-as-identifier.txt,
0002-Disallow-identifier-as-value.txt
The current grammar for CQL3 allows:
# uuid and integer constants as identifiers
# identifier as value (aka term in the grammar)
I think both of those should be removed.
For 1, mostly because this feels useless and slightly complicates the grammar
which is annoying for the documentation of CQL3 for instance (note that this
doesn't mean forbidding integer or uuid as identifier, but means they have to
be double-quoted when used as such).
For 2, I think that allowing identifier as value is actually misleading,
typically if you write things like {{SELECT foo WHERE foo=foo}}. It suggests
we support JOIN when we do not.
Also, if both are done, then one will always be able to distinguish between
identifier and value even without any context, which is a nice property.
--
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-4187) CQL3: move {max/min}_compaction_thresholds to compaction options
Sylvain Lebresne created CASSANDRA-4187:
---
Summary: CQL3: move {max/min}_compaction_thresholds to compaction
options
Key: CASSANDRA-4187
URL: https://issues.apache.org/jira/browse/CASSANDRA-4187
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.1.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Trivial
Fix For: 1.1.1
Attachments: 0001-Refactor-CFPropDefs-to-avoid-duplicate-code.txt,
0002-Move-min-max-compaction-threshold-settings-to-compacti.txt
It makes way more sense to have min_compaction_threshold and
max_compaction_threshold be parts of the compaction_strategy_options. They are
not in thrift (and CQL2) only for historical reasons, but there is no reason
not to fix it. Especially given that they don't make sense for all compaction
strategy (Leveled compaction ignores them).
--
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-4187) CQL3: move {max/min}_compaction_thresholds to compaction options
[
https://issues.apache.org/jira/browse/CASSANDRA-4187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4187:
Attachment: 0002-Move-min-max-compaction-threshold-settings-to-compacti.txt
0001-Refactor-CFPropDefs-to-avoid-duplicate-code.txt
Attached patches. The first is a small refactor to avoid code duplication, the
second is the actual change.
CQL3: move {max/min}_compaction_thresholds to compaction options
Key: CASSANDRA-4187
URL: https://issues.apache.org/jira/browse/CASSANDRA-4187
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.1.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Trivial
Labels: cql3
Fix For: 1.1.1
Attachments: 0001-Refactor-CFPropDefs-to-avoid-duplicate-code.txt,
0002-Move-min-max-compaction-threshold-settings-to-compacti.txt
It makes way more sense to have min_compaction_threshold and
max_compaction_threshold be parts of the compaction_strategy_options. They
are not in thrift (and CQL2) only for historical reasons, but there is no
reason not to fix it. Especially given that they don't make sense for all
compaction strategy (Leveled compaction ignores them).
--
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-4188) stress tool return a non-zero value when it fails
Tyler Patterson created CASSANDRA-4188: -- Summary: stress tool return a non-zero value when it fails Key: CASSANDRA-4188 URL: https://issues.apache.org/jira/browse/CASSANDRA-4188 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Tyler Patterson Priority: Minor I'm scripting the use of stress in the dtests, and it would be great if I could tell based on the return code if it succeeded or failed. -- 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-4189) Improve hints replay
Vijay created CASSANDRA-4189: Summary: Improve hints replay Key: CASSANDRA-4189 URL: https://issues.apache.org/jira/browse/CASSANDRA-4189 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 1.2 Problem: Hints are stored in one row. when there are a lot of hints stored and we store Tombstones for the ones which has been replayed. It might be worth shading the hints based on Hour at which the hints are stored. This can reduce the complexity of the scanning for hints. Problem: Hints replay is too slow and single threaded. There are use-case where the hints needs to be replayed ASAP to make the cluster more consistent. In Multi region cluster, the throttle is already done due to the latency which is in the order of 100's of millisecond. It might be worth trying to replay the hints in parallel and throttle on the number of bytes read from the disk or use the existing setting of throttle based on sleep interval on all the threads. -- 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-4190) Apparent data loss using super columns and row cache via ConcurrentLinkedHashCacheProvider
Mina Naguib created CASSANDRA-4190:
--
Summary: Apparent data loss using super columns and row cache via
ConcurrentLinkedHashCacheProvider
Key: CASSANDRA-4190
URL: https://issues.apache.org/jira/browse/CASSANDRA-4190
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.9
Environment: Linux 2.6.27
Reporter: Mina Naguib
Tested on a vanilla single-node cassandra 1.0.9 installation.
When using super columns along with row caching via
ConcurrentLinkedHashCacheProvider (default if no JNA available, or explicitly
configured even if JNA available), there's what appears as transient data loss.
Given this script executed in cassandra-cli:
{quote}
create keyspace Test;
use Test;
create column family Users with column_type='Super' and
key_validation_class='UTF8Type' and comparator='UTF8Type' and
subcomparator='UTF8Type' and default_validation_class='UTF8Type' and
rows_cached=75000 and row_cache_provider='ConcurrentLinkedHashCacheProvider';
set Users['mina']['attrs']['name'] = 'Mina';
get Users['mina'];
set Users['mina']['attrs']['country'] = 'Canada';
get Users['mina'];
set Users['mina']['attrs']['region'] = 'Quebec';
get Users['mina'];
{quote}
The output from the 3 gets above is as follows:
{quote}
= (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
{quote}
{quote}
= (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
{quote}
{quote}
= (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
{quote}
It's clear that the second and third set commands (country, region) are missing
in the returned results.
If the row cache is explicitly invalidated (in a second terminal, via `nodetool
-h localhost invalidaterowcache Test Users`), the missing data springs to life
on next 'get':
{quote}
[default@Test] get Users['mina'];
= (super_column=attrs,
(column=country, value=Canada, timestamp=1335377839592000)
(column=name, value=Mina, timestamp=1335377788441000)
(column=region, value=Quebec, timestamp=1335377871353000))
Returned 1 results.
{quote}
From cursory checks, this does not to appear to happen with regular columns,
nor with JNA enabled + SerializingCacheProvider.
--
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-4189) Improve hints replay
[ https://issues.apache.org/jira/browse/CASSANDRA-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261975#comment-13261975 ] Brandon Williams commented on CASSANDRA-4189: - bq. It might be worth shading the hints based on Hour at which the hints are stored. This can reduce the complexity of the scanning for hints. It's not clear to me that the extra code complexity (and IO) is worth this kind of tradeoff. Also, on (mis)completion we flush and force a compaction that should clear out the tombstones (see CASSANDRA-3733) so I'm skeptical this is a real problem. bq. Problem: Hints replay is too slow and single threaded. I disagree, historically our problem with hints has always been *overload*, which I think we finally got right in CASSANDRA-3554. Sure, in a two node cluster maybe the single threaded nature is a problem, but in any cluster of appreciable size it's always overload that's an issue, so I don't see much to be gained by multithreading it. Improve hints replay Key: CASSANDRA-4189 URL: https://issues.apache.org/jira/browse/CASSANDRA-4189 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 1.2 Problem: Hints are stored in one row. when there are a lot of hints stored and we store Tombstones for the ones which has been replayed. It might be worth shading the hints based on Hour at which the hints are stored. This can reduce the complexity of the scanning for hints. Problem: Hints replay is too slow and single threaded. There are use-case where the hints needs to be replayed ASAP to make the cluster more consistent. In Multi region cluster, the throttle is already done due to the latency which is in the order of 100's of millisecond. It might be worth trying to replay the hints in parallel and throttle on the number of bytes read from the disk or use the existing setting of throttle based on sleep interval on all the threads. -- 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-4189) Improve hints replay
[
https://issues.apache.org/jira/browse/CASSANDRA-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261991#comment-13261991
]
Vijay commented on CASSANDRA-4189:
--
{quote}
Also, on (mis)completion we flush and force a compaction that should clear out
the tombstones (see CASSANDRA-3733) so I'm skeptical this is a real problem.
{quote}
May be the above will fix it, the hints CF (about 10GB) is too large for the
node in question... so i have to do more tests.
{quote}
Sure, in a two node cluster maybe the single threaded nature is a problem, but
in any cluster of appreciable size it's always overload that's an issue, so I
don't see much to be gained by multithreading it.
{quote}
No the problem is when you have 10's of nodes and they are all in different
DC's, it is naturally throttled by the latency of 100's of milliseconds. Now
while replaying hints, the thread gets stuck replaying the hints to the remote
node, no other node gets the hints. What i am suggesting is to throttle but in
a multi threaded way.
Improve hints replay
Key: CASSANDRA-4189
URL: https://issues.apache.org/jira/browse/CASSANDRA-4189
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.2
Reporter: Vijay
Assignee: Vijay
Priority: Minor
Fix For: 1.2
Problem: Hints are stored in one row.
when there are a lot of hints stored and we store Tombstones for the ones
which has been replayed.
It might be worth shading the hints based on Hour at which the hints are
stored. This can reduce the complexity of the scanning for hints.
Problem: Hints replay is too slow and single threaded.
There are use-case where the hints needs to be replayed ASAP to make the
cluster more consistent.
In Multi region cluster, the throttle is already done due to the latency
which is in the order of 100's of millisecond.
It might be worth trying to replay the hints in parallel and throttle on the
number of bytes read from the disk or use the existing setting of throttle
based on sleep interval on all the threads.
--
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] Update of ClientOptions by ShawnBissell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ClientOptions page has been changed by ShawnBissell: http://wiki.apache.org/cassandra/ClientOptions?action=diffrev1=153rev2=154 * clj-hector: https://github.com/pingles/clj-hector * .NET * Aquiles: http://aquiles.codeplex.com/ + * Cassandraemon: http://cassandraemon.codeplex.com/ * cassandra-sharp: http://code.google.com/p/cassandra-sharp/ * FluentCassandra: https://github.com/managedfusion/fluentcassandra * Ruby:
[jira] [Commented] (CASSANDRA-4190) Apparent data loss using super columns and row cache via ConcurrentLinkedHashCacheProvider
[
https://issues.apache.org/jira/browse/CASSANDRA-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262005#comment-13262005
]
Mina Naguib commented on CASSANDRA-4190:
I can confirm that testing with cassandra 1.1.0 has the same conclusion.
To reproduce against cassandra 1.1.0, edit cassandra.yaml and set:
{quote}
row_cache_provider: ConcurrentLinkedHashCacheProvider
row_cache_size_in_mb: 200
{quote}
And use this slightly updated script to accomodate for 1.1.0 changes:
{quote}
create keyspace Test;
use Test;
create column family Users with column_type='Super' and
key_validation_class='UTF8Type' and comparator='UTF8Type' and
subcomparator='UTF8Type' and default_validation_class='UTF8Type' and
caching='ALL';
set Users['mina']['attrs']['name'] = 'Mina';
get Users['mina'];
set Users['mina']['attrs']['country'] = 'Canada';
get Users['mina'];
set Users['mina']['attrs']['region'] = 'Quebec';
get Users['mina'];
{quote}
The rest of the observations are the same as with the cassandra 1.0.9 test.
Apparent data loss using super columns and row cache via
ConcurrentLinkedHashCacheProvider
--
Key: CASSANDRA-4190
URL: https://issues.apache.org/jira/browse/CASSANDRA-4190
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.9
Environment: Linux 2.6.27
Reporter: Mina Naguib
Labels: ConcurrentLinkedHashCacheProvider, cache, supercolumns
Tested on a vanilla single-node cassandra 1.0.9 installation.
When using super columns along with row caching via
ConcurrentLinkedHashCacheProvider (default if no JNA available, or explicitly
configured even if JNA available), there's what appears as transient data
loss.
Given this script executed in cassandra-cli:
{quote}
create keyspace Test;
use Test;
create column family Users with column_type='Super' and
key_validation_class='UTF8Type' and comparator='UTF8Type' and
subcomparator='UTF8Type' and default_validation_class='UTF8Type' and
rows_cached=75000 and row_cache_provider='ConcurrentLinkedHashCacheProvider';
set Users['mina']['attrs']['name'] = 'Mina';
get Users['mina'];
set Users['mina']['attrs']['country'] = 'Canada';
get Users['mina'];
set Users['mina']['attrs']['region'] = 'Quebec';
get Users['mina'];
{quote}
The output from the 3 gets above is as follows:
{quote}
= (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
{quote}
{quote}
= (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
{quote}
{quote}
= (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
{quote}
It's clear that the second and third set commands (country, region) are
missing in the returned results.
If the row cache is explicitly invalidated (in a second terminal, via
`nodetool -h localhost invalidaterowcache Test Users`), the missing data
springs to life on next 'get':
{quote}
[default@Test] get Users['mina'];
= (super_column=attrs,
(column=country, value=Canada, timestamp=1335377839592000)
(column=name, value=Mina, timestamp=1335377788441000)
(column=region, value=Quebec, timestamp=1335377871353000))
Returned 1 results.
{quote}
From cursory checks, this does not to appear to happen with regular columns,
nor with JNA enabled + SerializingCacheProvider.
--
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-4188) stress tool return a non-zero value when it fails
[ https://issues.apache.org/jira/browse/CASSANDRA-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Patterson updated CASSANDRA-4188: --- Description: I'm using of stress in the dtests, and it would be great if I could tell based on the return code if stress succeeded or failed. (was: I'm scripting the use of stress in the dtests, and it would be great if I could tell based on the return code if it succeeded or failed.) stress tool return a non-zero value when it fails - Key: CASSANDRA-4188 URL: https://issues.apache.org/jira/browse/CASSANDRA-4188 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Tyler Patterson Priority: Minor Labels: stress I'm using of stress in the dtests, and it would be great if I could tell based on the return code if stress succeeded or failed. -- 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-4164) Cqlsh should support DESCRIBE on cql3-style composite CFs
[
https://issues.apache.org/jira/browse/CASSANDRA-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4164:
---
Attachment: 4164.patch.txt
teach cqlsh how to understand system.schema_columnfamilies so that it can get
information on composite primary key tables.
patch attached, or, as usual, in my 4164 branch on my github. tagged here:
https://github.com/thepaul/cassandra/tree/pending/4164
Note that this still won't work for describing composite CFs in the system
keyspace; system CFs don't show up in schema_columnfamilies, and there's no
other way to get key-component column info.
Cqlsh should support DESCRIBE on cql3-style composite CFs
-
Key: CASSANDRA-4164
URL: https://issues.apache.org/jira/browse/CASSANDRA-4164
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Nick Bailey
Assignee: paul cannon
Labels: cql3
Fix For: 1.1.1
Attachments: 4164.patch.txt
There is a discrepancy between create column family commands and then the
output of the describe command:
{noformat}
cqlsh:test CREATE TABLE timeline (
... user_id varchar,
... tweet_id uuid,
... author varchar,
... body varchar,
... PRIMARY KEY (user_id, tweet_id)
... );
cqlsh:test describe columnfamily timeline;
CREATE COLUMNFAMILY timeline (
user_id text PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.UUIDType,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='org.apache.cassandra.io.compress.SnappyCompressor';
{noformat}
--
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-4173) cqlsh: in cql3 mode, use cql3 quoting when outputting cql
[
https://issues.apache.org/jira/browse/CASSANDRA-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4173:
---
Attachment: 4173.patch.txt
break out calls to cql_escape so that they're separated by the sort of thing
being quoted (column/cf/keyspace name vs. value) and go through the Shell
object, so it can route to cql3 quoting or cql2 quoting as appropriate.
This should fix all uses of quoting except in tab completion areas.
Fix attached here and in the 4173 branch in my github, tagged here:
https://github.com/thepaul/cassandra/tree/pending/4173
The patch is meant to go on top of 4164.patch.txt from CASSANDRA-4164.
cqlsh: in cql3 mode, use cql3 quoting when outputting cql
-
Key: CASSANDRA-4173
URL: https://issues.apache.org/jira/browse/CASSANDRA-4173
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.1.0
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
Labels: cql3, cqlsh
Fix For: 1.1.1
Attachments: 4173.patch.txt
when cqlsh needs to output a column name or other term which needs quoting
(say, if you run DESCRIBE KEYSPACE and some column name has a space in it),
it currently only knows how to quote in the cql2 way. That is,
{noformat}
cqlsh:foo describe columnfamily bar
CREATE COLUMNFAMILY bar (
a int PRIMARY KEY,
'b c' text
) WITH
...
{noformat}
cql3 does not recognize single quotes around column names, or columnfamily or
keyspace names either. cqlsh ought to learn how to use double-quotes instead
when in cql3 mode.
--
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-4189) Improve hints replay
[ https://issues.apache.org/jira/browse/CASSANDRA-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262046#comment-13262046 ] Brandon Williams commented on CASSANDRA-4189: - bq. Now while replaying hints, the thread gets stuck replaying the hints to the remote node, no other node gets the hints. Ok, that makes sense. Improve hints replay Key: CASSANDRA-4189 URL: https://issues.apache.org/jira/browse/CASSANDRA-4189 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 1.2 Problem: Hints are stored in one row. when there are a lot of hints stored and we store Tombstones for the ones which has been replayed. It might be worth shading the hints based on Hour at which the hints are stored. This can reduce the complexity of the scanning for hints. Problem: Hints replay is too slow and single threaded. There are use-case where the hints needs to be replayed ASAP to make the cluster more consistent. In Multi region cluster, the throttle is already done due to the latency which is in the order of 100's of millisecond. It might be worth trying to replay the hints in parallel and throttle on the number of bytes read from the disk or use the existing setting of throttle based on sleep interval on all the threads. -- 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-4188) stress tool return a non-zero value when it fails
[ https://issues.apache.org/jira/browse/CASSANDRA-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4188: Fix Version/s: 1.0.10 stress tool return a non-zero value when it fails - Key: CASSANDRA-4188 URL: https://issues.apache.org/jira/browse/CASSANDRA-4188 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Tyler Patterson Assignee: Pavel Yaskevich Priority: Minor Labels: stress Fix For: 1.0.10 I'm using of stress in the dtests, and it would be great if I could tell based on the return code if stress succeeded or failed. -- 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] [Assigned] (CASSANDRA-4188) stress tool return a non-zero value when it fails
[ https://issues.apache.org/jira/browse/CASSANDRA-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-4188: --- Assignee: Pavel Yaskevich stress tool return a non-zero value when it fails - Key: CASSANDRA-4188 URL: https://issues.apache.org/jira/browse/CASSANDRA-4188 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Tyler Patterson Assignee: Pavel Yaskevich Priority: Minor Labels: stress Fix For: 1.0.10 I'm using of stress in the dtests, and it would be great if I could tell based on the return code if stress succeeded or failed. -- 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] [Assigned] (CASSANDRA-4190) Apparent data loss using super columns and row cache via ConcurrentLinkedHashCacheProvider
[
https://issues.apache.org/jira/browse/CASSANDRA-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-4190:
-
Assignee: Sylvain Lebresne
Apparent data loss using super columns and row cache via
ConcurrentLinkedHashCacheProvider
--
Key: CASSANDRA-4190
URL: https://issues.apache.org/jira/browse/CASSANDRA-4190
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.9
Environment: Linux 2.6.27
Reporter: Mina Naguib
Assignee: Sylvain Lebresne
Labels: ConcurrentLinkedHashCacheProvider, cache, supercolumns
Tested on a vanilla single-node cassandra 1.0.9 installation.
When using super columns along with row caching via
ConcurrentLinkedHashCacheProvider (default if no JNA available, or explicitly
configured even if JNA available), there's what appears as transient data
loss.
Given this script executed in cassandra-cli:
{quote}
create keyspace Test;
use Test;
create column family Users with column_type='Super' and
key_validation_class='UTF8Type' and comparator='UTF8Type' and
subcomparator='UTF8Type' and default_validation_class='UTF8Type' and
rows_cached=75000 and row_cache_provider='ConcurrentLinkedHashCacheProvider';
set Users['mina']['attrs']['name'] = 'Mina';
get Users['mina'];
set Users['mina']['attrs']['country'] = 'Canada';
get Users['mina'];
set Users['mina']['attrs']['region'] = 'Quebec';
get Users['mina'];
{quote}
The output from the 3 gets above is as follows:
{quote}
= (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
{quote}
{quote}
= (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
{quote}
{quote}
= (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
{quote}
It's clear that the second and third set commands (country, region) are
missing in the returned results.
If the row cache is explicitly invalidated (in a second terminal, via
`nodetool -h localhost invalidaterowcache Test Users`), the missing data
springs to life on next 'get':
{quote}
[default@Test] get Users['mina'];
= (super_column=attrs,
(column=country, value=Canada, timestamp=1335377839592000)
(column=name, value=Mina, timestamp=1335377788441000)
(column=region, value=Quebec, timestamp=1335377871353000))
Returned 1 results.
{quote}
From cursory checks, this does not to appear to happen with regular columns,
nor with JNA enabled + SerializingCacheProvider.
--
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-4188) stress tool return a non-zero value when it fails
[ https://issues.apache.org/jira/browse/CASSANDRA-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262051#comment-13262051 ] Jonathan Ellis commented on CASSANDRA-4188: --- What is succeeded for stress? Is timing out once a failure? Or taking longer than X minutes? stress tool return a non-zero value when it fails - Key: CASSANDRA-4188 URL: https://issues.apache.org/jira/browse/CASSANDRA-4188 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Tyler Patterson Assignee: Pavel Yaskevich Priority: Minor Labels: stress Fix For: 1.0.10 I'm using of stress in the dtests, and it would be great if I could tell based on the return code if stress succeeded or failed. -- 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-4188) stress tool return a non-zero value when it fails
[ https://issues.apache.org/jira/browse/CASSANDRA-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262053#comment-13262053 ] Pavel Yaskevich commented on CASSANDRA-4188: No, it just returns normally but you will see the error messages in the log (with number of retries and other additional info such as exception type/message). stress tool return a non-zero value when it fails - Key: CASSANDRA-4188 URL: https://issues.apache.org/jira/browse/CASSANDRA-4188 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Tyler Patterson Assignee: Pavel Yaskevich Priority: Minor Labels: stress Fix For: 1.0.10 I'm using of stress in the dtests, and it would be great if I could tell based on the return code if stress succeeded or failed. -- 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-4189) Improve hints replay
[ https://issues.apache.org/jira/browse/CASSANDRA-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262066#comment-13262066 ] Jonathan Ellis commented on CASSANDRA-4189: --- bq. It might be worth shading the hints based on Hour at which the hints are stored. This can reduce the complexity of the scanning for hints. Not sure this is a problem now that we drop the tombstones after each handoff. Since there is only one handoff per target at a time, we don't need to worry about having to skip tombstones in a meaningful volume. bq. What i am suggesting is to throttle but in a multi threaded way +1 Improve hints replay Key: CASSANDRA-4189 URL: https://issues.apache.org/jira/browse/CASSANDRA-4189 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 1.2 Problem: Hints are stored in one row. when there are a lot of hints stored and we store Tombstones for the ones which has been replayed. It might be worth shading the hints based on Hour at which the hints are stored. This can reduce the complexity of the scanning for hints. Problem: Hints replay is too slow and single threaded. There are use-case where the hints needs to be replayed ASAP to make the cluster more consistent. In Multi region cluster, the throttle is already done due to the latency which is in the order of 100's of millisecond. It might be worth trying to replay the hints in parallel and throttle on the number of bytes read from the disk or use the existing setting of throttle based on sleep interval on all the threads. -- 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-4164) Cqlsh should support DESCRIBE on cql3-style composite CFs
[
https://issues.apache.org/jira/browse/CASSANDRA-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4164:
--
Reviewer: brandon.williams
Cqlsh should support DESCRIBE on cql3-style composite CFs
-
Key: CASSANDRA-4164
URL: https://issues.apache.org/jira/browse/CASSANDRA-4164
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Nick Bailey
Assignee: paul cannon
Labels: cql3
Fix For: 1.1.1
Attachments: 4164.patch.txt
There is a discrepancy between create column family commands and then the
output of the describe command:
{noformat}
cqlsh:test CREATE TABLE timeline (
... user_id varchar,
... tweet_id uuid,
... author varchar,
... body varchar,
... PRIMARY KEY (user_id, tweet_id)
... );
cqlsh:test describe columnfamily timeline;
CREATE COLUMNFAMILY timeline (
user_id text PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.UUIDType,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='org.apache.cassandra.io.compress.SnappyCompressor';
{noformat}
--
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-4173) cqlsh: in cql3 mode, use cql3 quoting when outputting cql
[
https://issues.apache.org/jira/browse/CASSANDRA-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4173:
--
Reviewer: brandon.williams
cqlsh: in cql3 mode, use cql3 quoting when outputting cql
-
Key: CASSANDRA-4173
URL: https://issues.apache.org/jira/browse/CASSANDRA-4173
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.1.0
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
Labels: cql3, cqlsh
Fix For: 1.1.1
Attachments: 4173.patch.txt
when cqlsh needs to output a column name or other term which needs quoting
(say, if you run DESCRIBE KEYSPACE and some column name has a space in it),
it currently only knows how to quote in the cql2 way. That is,
{noformat}
cqlsh:foo describe columnfamily bar
CREATE COLUMNFAMILY bar (
a int PRIMARY KEY,
'b c' text
) WITH
...
{noformat}
cql3 does not recognize single quotes around column names, or columnfamily or
keyspace names either. cqlsh ought to learn how to use double-quotes instead
when in cql3 mode.
--
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-4188) stress tool return a non-zero value when it fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262089#comment-13262089
]
Tyler Patterson commented on CASSANDRA-4188:
{quote}What is succeeded for stress? Is timing out once a failure? Or taking
longer than X minutes?{quote}
I was thinking of capturing obvious failures, like when it hits the max number
of retries. Pretty much any time that it used to hang indefinitely.
stress tool return a non-zero value when it fails
-
Key: CASSANDRA-4188
URL: https://issues.apache.org/jira/browse/CASSANDRA-4188
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Priority: Minor
Labels: stress
Fix For: 1.0.10
I'm using of stress in the dtests, and it would be great if I could tell
based on the return code if stress succeeded or failed.
--
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-4188) stress tool return a non-zero value when it fails
[ https://issues.apache.org/jira/browse/CASSANDRA-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262094#comment-13262094 ] Pavel Yaskevich commented on CASSANDRA-4188: bq. I was thinking of capturing obvious failures, like when it hits the max number of retries. Pretty much any time that it used to hang indefinitely. That was fixed by CASSANDRA-4128 stress tool return a non-zero value when it fails - Key: CASSANDRA-4188 URL: https://issues.apache.org/jira/browse/CASSANDRA-4188 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Tyler Patterson Assignee: Pavel Yaskevich Priority: Minor Labels: stress Fix For: 1.0.10 I'm using of stress in the dtests, and it would be great if I could tell based on the return code if stress succeeded or failed. -- 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-4190) Apparent data loss using super columns and row cache via ConcurrentLinkedHashCacheProvider
[
https://issues.apache.org/jira/browse/CASSANDRA-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mina Naguib updated CASSANDRA-4190:
---
Affects Version/s: 1.1.0
Apparent data loss using super columns and row cache via
ConcurrentLinkedHashCacheProvider
--
Key: CASSANDRA-4190
URL: https://issues.apache.org/jira/browse/CASSANDRA-4190
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.9, 1.1.0
Environment: Linux 2.6.27
Reporter: Mina Naguib
Assignee: Sylvain Lebresne
Labels: ConcurrentLinkedHashCacheProvider, cache, supercolumns
Tested on a vanilla single-node cassandra 1.0.9 installation.
When using super columns along with row caching via
ConcurrentLinkedHashCacheProvider (default if no JNA available, or explicitly
configured even if JNA available), there's what appears as transient data
loss.
Given this script executed in cassandra-cli:
{quote}
create keyspace Test;
use Test;
create column family Users with column_type='Super' and
key_validation_class='UTF8Type' and comparator='UTF8Type' and
subcomparator='UTF8Type' and default_validation_class='UTF8Type' and
rows_cached=75000 and row_cache_provider='ConcurrentLinkedHashCacheProvider';
set Users['mina']['attrs']['name'] = 'Mina';
get Users['mina'];
set Users['mina']['attrs']['country'] = 'Canada';
get Users['mina'];
set Users['mina']['attrs']['region'] = 'Quebec';
get Users['mina'];
{quote}
The output from the 3 gets above is as follows:
{quote}
= (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
{quote}
{quote}
= (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
{quote}
{quote}
= (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
{quote}
It's clear that the second and third set commands (country, region) are
missing in the returned results.
If the row cache is explicitly invalidated (in a second terminal, via
`nodetool -h localhost invalidaterowcache Test Users`), the missing data
springs to life on next 'get':
{quote}
[default@Test] get Users['mina'];
= (super_column=attrs,
(column=country, value=Canada, timestamp=1335377839592000)
(column=name, value=Mina, timestamp=1335377788441000)
(column=region, value=Quebec, timestamp=1335377871353000))
Returned 1 results.
{quote}
From cursory checks, this does not to appear to happen with regular columns,
nor with JNA enabled + SerializingCacheProvider.
--
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-4191) Add `nodetool cfstats ks cf` abilities
Joaquin Casares created CASSANDRA-4191: -- Summary: Add `nodetool cfstats ks cf` abilities Key: CASSANDRA-4191 URL: https://issues.apache.org/jira/browse/CASSANDRA-4191 Project: Cassandra Issue Type: New Feature Affects Versions: 1.0.0 Reporter: Joaquin Casares Priority: Minor This way cfstats will only print information per keyspace/column family combinations. Another related proposal as an alternative to this ticket: Allow for `nodetool cfstats` to use --excludes or --includes to accept keyspace and column family arguments. -- 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-4191) Add `nodetool cfstats ks cf` abilities
[ https://issues.apache.org/jira/browse/CASSANDRA-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262299#comment-13262299 ] Jonathan Ellis commented on CASSANDRA-4191: --- Would prefer list-to-include and list-to-exclude personally. I most freguently want to see everything but system. However defaulting to everything-but-system with option to do list-to-include instead, would also work for me. (I do think we should definitely support a list of CFs, not just a single one; the former is a superset of the latter, obviously.) Add `nodetool cfstats ks cf` abilities -- Key: CASSANDRA-4191 URL: https://issues.apache.org/jira/browse/CASSANDRA-4191 Project: Cassandra Issue Type: New Feature Affects Versions: 1.0.0 Reporter: Joaquin Casares Priority: Minor Labels: datastax_qa This way cfstats will only print information per keyspace/column family combinations. Another related proposal as an alternative to this ticket: Allow for `nodetool cfstats` to use --excludes or --includes to accept keyspace and column family arguments. -- 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
