date:20130905


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis resolved CASSANDRA-5977.
---

Resolution: Not A Problem

If you want it structured you should grab it from JMX directly.  Nodetool 
exists to turn JMX into human-readable output, not to transform JMX into 
alternative machine-readable formats.

 Structure for cfstats output (JSON, YAML, or XML)
 -

 Key: CASSANDRA-5977
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5977
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Alyssa Kwan
Priority: Minor

 nodetool cfstats should take a --format arg that structures the output in 
 JSON, YAML, or XML.  This would be useful for piping into another script that 
 can easily parse this and act on it.  It would also help those of us who use 
 things like MCollective gather aggregate stats across clusters/nodes.
 Thoughts?  I can submit a patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-5978) stressd broken by ClientEncriptionOptions

2013-09-05 Thread Jeremiah Jordan (JIRA)

Jeremiah Jordan created CASSANDRA-5978:
--

 Summary: stressd broken by ClientEncriptionOptions
 Key: CASSANDRA-5978
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5978
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Priority: Minor


The ClientEncryptionOptions object added to org.apache.cassandra.stress.Session 
is not Serializable.  So if you try to use stress with stressd, the Session 
can't be serialized to be passed over to stressd:

{noformat}
Exception in thread main java.io.NotSerializableException: 
org.apache.cassandra.config.EncryptionOptions$ClientEncryptionOptions
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at org.apache.cassandra.stress.Stress.main(Unknown Source)
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: Rename clustering keys to clustering columns in doc

Updated Branches:
  refs/heads/cassandra-1.2 c49ad3ccf - 1f6844261


Rename clustering keys to clustering columns in doc


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1f684426
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1f684426
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1f684426

Branch: refs/heads/cassandra-1.2
Commit: 1f6844261a83d48724be8fd172b7bf3a9018607a
Parents: c49ad3c
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 5 16:35:18 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 5 16:35:18 2013 +0200

--
 doc/cql3/CQL.textile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f684426/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index bb9a632..168a05d 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -281,7 +281,7 @@ h4(#createTablepartitionClustering). Partition key and 
clustering
 
 In CQL, the order in which columns are defined for the @PRIMARY KEY@ matters. 
The first column of the key is called the __partition key__. It has the 
property that all the rows sharing the same partition key (even across table in 
fact) are stored on the same physical node. Also, insertion/update/deletion on 
rows sharing the same partition key for a given table are performed 
__atomically__ and in __isolation__. Note that it is possible to have a 
composite partition key, i.e. a partition key formed of multiple columns, using 
an extra set of parentheses to define which columns forms the partition key.
 
-The remaining columns of the @PRIMARY KEY@ definition, if any, are called 
__clustering keys__. On a given physical node, rows for a given partition key 
are stored in the order induced by the clustering keys, making the retrieval of 
rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a).
+The remaining columns of the @PRIMARY KEY@ definition, if any, are called 
__clustering columns. On a given physical node, rows for a given partition key 
are stored in the order induced by the clustering columns, making the retrieval 
of rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a).
 
 h4(#createTableOptions). @option@
 
@@ -360,7 +360,7 @@ p.
 The @ALTER@ statement is used to manipulate table definitions. It allows to 
add new columns, drop existing ones, change the type of existing columns, or 
update the table options. As for table creation, @ALTER COLUMNFAMILY@ is 
allowed as an alias for @ALTER TABLE@.
 
 The @tablename@ is the table name optionally preceded by the keyspace name.  
The @instruction@ defines the alteration to perform:
-* @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering keys:#createTablepartitionClustering cannot be modified as it 
induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
+* @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering columns:#createTablepartitionClustering cannot be modified as 
it induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
 * @ADD@: Adds a new column to the table. The @identifier@ for the new column 
must not conflict with an existing column. Moreover, columns cannot be added to 
tables defined with the @COMPACT STORAGE@ option.
 * @WITH@: Allows to update the options of the table. The supported 
@option@:#createTableOptions (and syntax) are the same as for the @CREATE 
TABLE@ statement except that @COMPACT STORAGE@ is not supported. Note that 
setting any @compaction@ sub-options has the effect of erasing all previous 
@compaction@ options, so you  need to re-specify all the sub-options if you 
want to keep them. The same note applies to the set of @compression@ 
sub-options.
 
@@ -634,7 +634,7 @@ h4(#selectWhere). @where-clause@
 
 The @where-clause@ specifies which rows must be queried. It is composed of 
relations on the columns that are part of the @PRIMARY KEY@

[2/2] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

Merge branch 'cassandra-1.2' into cassandra-2.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/12671160
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/12671160
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/12671160

Branch: refs/heads/cassandra-2.0
Commit: 12671160bda849bc80b69e521885169c6eb462e0
Parents: edc7531 1f68442
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 5 16:37:08 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 5 16:37:08 2013 +0200

--
 doc/cql3/CQL.textile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/12671160/doc/cql3/CQL.textile
--
diff --cc doc/cql3/CQL.textile
index e8f991b,168a05d..178d940
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@@ -367,11 -360,12 +367,11 @@@ p
  The @ALTER@ statement is used to manipulate table definitions. It allows to 
add new columns, drop existing ones, change the type of existing columns, or 
update the table options. As for table creation, @ALTER COLUMNFAMILY@ is 
allowed as an alias for @ALTER TABLE@.
  
  The @tablename@ is the table name optionally preceded by the keyspace name. 
 The @instruction@ defines the alteration to perform:
- * @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering keys:#createTablepartitionClustering cannot be modified as it 
induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
+ * @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering columns:#createTablepartitionClustering cannot be modified as 
it induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
  * @ADD@: Adds a new column to the table. The @identifier@ for the new 
column must not conflict with an existing column. Moreover, columns cannot be 
added to tables defined with the @COMPACT STORAGE@ option.
 +* @DROP@: Removes a column from the table. Dropped columns will immediately 
become unavailable in the queries and will not be included in compacted 
sstables in the future. If a column is readded, queries won't return values 
written before the column was last dropped. It is assumed that timestamps 
represent actual time, so if this is not your case, you should NOT readd 
previously dropped columns. Columns can't be dropped from tables defined with 
the @COMPACT STORAGE@ option.
  * @WITH@: Allows to update the options of the table. The supported 
@option@:#createTableOptions (and syntax) are the same as for the @CREATE 
TABLE@ statement except that @COMPACT STORAGE@ is not supported. Note that 
setting any @compaction@ sub-options has the effect of erasing all previous 
@compaction@ options, so you  need to re-specify all the sub-options if you 
want to keep them. The same note applies to the set of @compression@ 
sub-options.
  
 -Dropping a column is no yet supported but is on the 
roadmap:https://issues.apache.org/jira/browse/CASSANDRA-3919. In the meantime, 
a declared but unused column has no impact on performance nor uses any storage.
 -
  h3(#dropTableStmt). DROP TABLE
  
  __Syntax:__

[1/2] git commit: Rename clustering keys to clustering columns in doc

Updated Branches:
  refs/heads/cassandra-2.0 edc753127 - 12671160b


Rename clustering keys to clustering columns in doc


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1f684426
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1f684426
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1f684426

Branch: refs/heads/cassandra-2.0
Commit: 1f6844261a83d48724be8fd172b7bf3a9018607a
Parents: c49ad3c
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 5 16:35:18 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 5 16:35:18 2013 +0200

--
 doc/cql3/CQL.textile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f684426/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index bb9a632..168a05d 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -281,7 +281,7 @@ h4(#createTablepartitionClustering). Partition key and 
clustering
 
 In CQL, the order in which columns are defined for the @PRIMARY KEY@ matters. 
The first column of the key is called the __partition key__. It has the 
property that all the rows sharing the same partition key (even across table in 
fact) are stored on the same physical node. Also, insertion/update/deletion on 
rows sharing the same partition key for a given table are performed 
__atomically__ and in __isolation__. Note that it is possible to have a 
composite partition key, i.e. a partition key formed of multiple columns, using 
an extra set of parentheses to define which columns forms the partition key.
 
-The remaining columns of the @PRIMARY KEY@ definition, if any, are called 
__clustering keys__. On a given physical node, rows for a given partition key 
are stored in the order induced by the clustering keys, making the retrieval of 
rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a).
+The remaining columns of the @PRIMARY KEY@ definition, if any, are called 
__clustering columns. On a given physical node, rows for a given partition key 
are stored in the order induced by the clustering columns, making the retrieval 
of rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a).
 
 h4(#createTableOptions). @option@
 
@@ -360,7 +360,7 @@ p.
 The @ALTER@ statement is used to manipulate table definitions. It allows to 
add new columns, drop existing ones, change the type of existing columns, or 
update the table options. As for table creation, @ALTER COLUMNFAMILY@ is 
allowed as an alias for @ALTER TABLE@.
 
 The @tablename@ is the table name optionally preceded by the keyspace name.  
The @instruction@ defines the alteration to perform:
-* @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering keys:#createTablepartitionClustering cannot be modified as it 
induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
+* @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering columns:#createTablepartitionClustering cannot be modified as 
it induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
 * @ADD@: Adds a new column to the table. The @identifier@ for the new column 
must not conflict with an existing column. Moreover, columns cannot be added to 
tables defined with the @COMPACT STORAGE@ option.
 * @WITH@: Allows to update the options of the table. The supported 
@option@:#createTableOptions (and syntax) are the same as for the @CREATE 
TABLE@ statement except that @COMPACT STORAGE@ is not supported. Note that 
setting any @compaction@ sub-options has the effect of erasing all previous 
@compaction@ options, so you  need to re-specify all the sub-options if you 
want to keep them. The same note applies to the set of @compression@ 
sub-options.
 
@@ -634,7 +634,7 @@ h4(#selectWhere). @where-clause@
 
 The @where-clause@ specifies which rows must be queried. It is composed of 
relations on the columns that are part of the @PRIMARY KEY@

[1/3] git commit: Rename clustering keys to clustering columns in doc

Updated Branches:
  refs/heads/trunk a17fac984 - a9005cbb5


Rename clustering keys to clustering columns in doc


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1f684426
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1f684426
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1f684426

Branch: refs/heads/trunk
Commit: 1f6844261a83d48724be8fd172b7bf3a9018607a
Parents: c49ad3c
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 5 16:35:18 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 5 16:35:18 2013 +0200

--
 doc/cql3/CQL.textile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f684426/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index bb9a632..168a05d 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -281,7 +281,7 @@ h4(#createTablepartitionClustering). Partition key and 
clustering
 
 In CQL, the order in which columns are defined for the @PRIMARY KEY@ matters. 
The first column of the key is called the __partition key__. It has the 
property that all the rows sharing the same partition key (even across table in 
fact) are stored on the same physical node. Also, insertion/update/deletion on 
rows sharing the same partition key for a given table are performed 
__atomically__ and in __isolation__. Note that it is possible to have a 
composite partition key, i.e. a partition key formed of multiple columns, using 
an extra set of parentheses to define which columns forms the partition key.
 
-The remaining columns of the @PRIMARY KEY@ definition, if any, are called 
__clustering keys__. On a given physical node, rows for a given partition key 
are stored in the order induced by the clustering keys, making the retrieval of 
rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a).
+The remaining columns of the @PRIMARY KEY@ definition, if any, are called 
__clustering columns. On a given physical node, rows for a given partition key 
are stored in the order induced by the clustering columns, making the retrieval 
of rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a).
 
 h4(#createTableOptions). @option@
 
@@ -360,7 +360,7 @@ p.
 The @ALTER@ statement is used to manipulate table definitions. It allows to 
add new columns, drop existing ones, change the type of existing columns, or 
update the table options. As for table creation, @ALTER COLUMNFAMILY@ is 
allowed as an alias for @ALTER TABLE@.
 
 The @tablename@ is the table name optionally preceded by the keyspace name.  
The @instruction@ defines the alteration to perform:
-* @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering keys:#createTablepartitionClustering cannot be modified as it 
induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
+* @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering columns:#createTablepartitionClustering cannot be modified as 
it induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
 * @ADD@: Adds a new column to the table. The @identifier@ for the new column 
must not conflict with an existing column. Moreover, columns cannot be added to 
tables defined with the @COMPACT STORAGE@ option.
 * @WITH@: Allows to update the options of the table. The supported 
@option@:#createTableOptions (and syntax) are the same as for the @CREATE 
TABLE@ statement except that @COMPACT STORAGE@ is not supported. Note that 
setting any @compaction@ sub-options has the effect of erasing all previous 
@compaction@ options, so you  need to re-specify all the sub-options if you 
want to keep them. The same note applies to the set of @compression@ 
sub-options.
 
@@ -634,7 +634,7 @@ h4(#selectWhere). @where-clause@
 
 The @where-clause@ specifies which rows must be queried. It is composed of 
relations on the columns that are part of the @PRIMARY KEY@ and/or have a

[3/3] git commit: Merge branch 'cassandra-2.0' into trunk

Merge branch 'cassandra-2.0' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a9005cbb
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a9005cbb
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a9005cbb

Branch: refs/heads/trunk
Commit: a9005cbb5aab006f8a7b0199d5d11d1d1b1adf82
Parents: a17fac9 1267116
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 5 16:37:50 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 5 16:37:50 2013 +0200

--
 doc/cql3/CQL.textile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--

[2/3] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

Merge branch 'cassandra-1.2' into cassandra-2.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/12671160
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/12671160
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/12671160

Branch: refs/heads/trunk
Commit: 12671160bda849bc80b69e521885169c6eb462e0
Parents: edc7531 1f68442
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 5 16:37:08 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 5 16:37:08 2013 +0200

--
 doc/cql3/CQL.textile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/12671160/doc/cql3/CQL.textile
--
diff --cc doc/cql3/CQL.textile
index e8f991b,168a05d..178d940
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@@ -367,11 -360,12 +367,11 @@@ p
  The @ALTER@ statement is used to manipulate table definitions. It allows to 
add new columns, drop existing ones, change the type of existing columns, or 
update the table options. As for table creation, @ALTER COLUMNFAMILY@ is 
allowed as an alias for @ALTER TABLE@.
  
  The @tablename@ is the table name optionally preceded by the keyspace name. 
 The @instruction@ defines the alteration to perform:
- * @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering keys:#createTablepartitionClustering cannot be modified as it 
induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
+ * @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering columns:#createTablepartitionClustering cannot be modified as 
it induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
  * @ADD@: Adds a new column to the table. The @identifier@ for the new 
column must not conflict with an existing column. Moreover, columns cannot be 
added to tables defined with the @COMPACT STORAGE@ option.
 +* @DROP@: Removes a column from the table. Dropped columns will immediately 
become unavailable in the queries and will not be included in compacted 
sstables in the future. If a column is readded, queries won't return values 
written before the column was last dropped. It is assumed that timestamps 
represent actual time, so if this is not your case, you should NOT readd 
previously dropped columns. Columns can't be dropped from tables defined with 
the @COMPACT STORAGE@ option.
  * @WITH@: Allows to update the options of the table. The supported 
@option@:#createTableOptions (and syntax) are the same as for the @CREATE 
TABLE@ statement except that @COMPACT STORAGE@ is not supported. Note that 
setting any @compaction@ sub-options has the effect of erasing all previous 
@compaction@ options, so you  need to re-specify all the sub-options if you 
want to keep them. The same note applies to the set of @compression@ 
sub-options.
  
 -Dropping a column is no yet supported but is on the 
roadmap:https://issues.apache.org/jira/browse/CASSANDRA-3919. In the meantime, 
a declared but unused column has no impact on performance nor uses any storage.
 -
  h3(#dropTableStmt). DROP TABLE
  
  __Syntax:__

svn commit: r1520330 [1/2] - in /cassandra/site/publish/doc/cql3: CQL-1.2.html CQL-2.0.html

Author: slebresne
Date: Thu Sep  5 14:38:29 2013
New Revision: 1520330

URL: http://svn.apache.org/r1520330
Log:
CQL doc update

Modified:
cassandra/site/publish/doc/cql3/CQL-1.2.html
cassandra/site/publish/doc/cql3/CQL-2.0.html

Modified: cassandra/site/publish/doc/cql3/CQL-1.2.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/doc/cql3/CQL-1.2.html?rev=1520330r1=1520329r2=1520330view=diff
==
--- cassandra/site/publish/doc/cql3/CQL-1.2.html (original)
+++ cassandra/site/publish/doc/cql3/CQL-1.2.html Thu Sep  5 14:38:29 2013
@@ -93,7 +93,7 @@ CREATE TABLE timeline (
 other text,
 PRIMARY KEY (k)
 )
-/pre/prepMoreover, a table must define at least one column that is not 
part of the PRIMARY KEY as a row exists in Cassandra only if it contains at 
least one value for one such column./ph4 
id=createTablepartitionClusteringPartition key and clustering/h4pIn CQL, 
the order in which columns are defined for the codePRIMARY KEY/code 
matters. The first column of the key is called the ipartition key/i. It has 
the property that all the rows sharing the same partition key (even across 
table in fact) are stored on the same physical node. Also, 
insertion/update/deletion on rows sharing the same partition key for a given 
table are performed iatomically/i and in iisolation/i. Note that it is 
possible to have a composite partition key, i.e. a partition key formed of 
multiple columns, using an extra set of parentheses to define which columns 
forms the partition key./ppThe remaining columns of the codePRIMARY 
KEY/code definition, if any, are called iclusteri
 ng keys/i. On a given physical node, rows for a given partition key are 
stored in the order induced by the clustering keys, making the retrieval of 
rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a)./ph4 
id=createTableOptionscodelt;option/code/h4pThe codeCREATE 
TABLE/code statement supports a number of options that controls the 
configuration of a new table. These options can be specified after the 
codeWITH/code keyword./ppThe first of these option is codeCOMPACT 
STORAGE/code. This option is meanly targeted towards backward compatibility 
with some table definition created before CQL3.  But it also provides a 
slightly more compact layout of data on disk, though at the price of 
flexibility and extensibility, and for that reason is not recommended unless 
for the backward compatibility reason. The restriction for table with 
codeCOMPACT STORAGE/code is that they support one and only one column 
outside 
 of the ones part of the codePRIMARY KEY/code. It also follows that columns 
cannot be added nor removed after creation. A table with codeCOMPACT 
STORAGE/code must also define at least one a 
href=createTablepartitionClusteringclustering key/a./ppAnother option 
is codeCLUSTERING ORDER/code. It allows to define the ordering of rows on 
disk. It takes the list of the clustering key names with, for each of them, the 
on-disk order (Ascending or descending). Note that this option affects a 
href=#selectOrderBywhat codeORDER BY/code are allowed during 
codeSELECT/code/a./ppTable creation supports the following other 
codelt;property/code:/ptabletrthoption
/ththkind   /ththdefault   
/ththdescription/th/trtrtdcodecomment/code
/tdtdemsimple/em /tdtdnone/tdtdA free-form, 
human-readable comment./td/trtrtdcoderead_repair_chance/code
 /tdtde
 msimple/em /tdtd0.1 /tdtdThe probability with which to 
query extra nodes (e.g. more nodes than required by the consistency level) for 
the purpose of read 
repairs./td/trtrtdcodedclocal_read_repair_chance/code 
/tdtdemsimple/em /tdtd0   /tdtdThe probability with 
which to query extra nodes (e.g. more nodes than required by the consistency 
level) belonging to the same data center than the read coordinator for the 
purpose of read repairs./td/trtrtdcodegc_grace_seconds/code 
  /tdtdemsimple/em /tdtd864000  /tdtdTime to wait before 
garbage collecting tombstones (deletion 
markers)./td/trtrtdcodebloom_filter_fp_chance/code 
/tdtdemsimple/em /tdtd0.00075 /tdtdThe target probability 
of false positive of the sstable bloom filters. Said bloom filters will be 
sized to provide the provided probability (thus lowering this value impact the 
size of bloom filters in-memory an
 d on-disk)/td/trtrtdcodecompaction/code 
/tdtdemmap/em/tdtdemsee below/em /tdtdThe compaction 
otpions to use, see below./td/trtrtdcodecompression/code
/tdtdemmap/em/tdtdemsee below/em /tdtdCompression 
options, see below. /td/trtrtdcodereplicate_on_write/code 
/tdtdemsimple/em /tdtdtrue/tdtdWhether to replicate 
data on write. This can only be set to false for tables with counters values. 
Disabling this is dangerous and can result in random lose of counters, 
don#8217;t

[jira] [Resolved] (CASSANDRA-5104) new nodes should not attempt to bootstrap and stream until entire cluster is on the same major version


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis resolved CASSANDRA-5104.
---

   Resolution: Not A Problem
Fix Version/s: (was: 2.0.1)

+1

 new nodes should not attempt to bootstrap and stream until entire cluster is 
 on the same major version
 --

 Key: CASSANDRA-5104
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5104
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Michael Kjellman
Assignee: Yuki Morishita
Priority: Minor

 current behavior for bootstrapping nodes is for an exception to be thrown 
 while a node attempts to stream from another node that has not had 
 upgradesstables run yet.
 A node should not attempt to bootstrap into the cluster until the entire 
 cluster is on the same major version and upgradesstables has already been run 
 on every node in the ring.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[1/6] git commit: update build.xml for metrics-core 2.2.0

Updated Branches:
  refs/heads/cassandra-1.2 1f6844261 - 3d9c3dd3a
  refs/heads/cassandra-2.0 12671160b - 85be04bb2
  refs/heads/trunk a9005cbb5 - a6f036178


update build.xml for metrics-core 2.2.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3d9c3dd3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3d9c3dd3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3d9c3dd3

Branch: refs/heads/cassandra-1.2
Commit: 3d9c3dd3afe2627eac49db7cfd0764b9e3ef857e
Parents: 1f68442
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Sep 5 11:04:20 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Sep 5 11:04:26 2013 -0500

--
 build.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3d9c3dd3/build.xml
--
diff --git a/build.xml b/build.xml
index 9e1de8d..122759c 100644
--- a/build.xml
+++ b/build.xml
@@ -383,7 +383,7 @@
   dependency groupId=log4j artifactId=log4j version=1.2.16 /
   dependency groupId=org.apache.cassandra 
artifactId=cassandra-all version=${version} /
   dependency groupId=org.apache.cassandra 
artifactId=cassandra-thrift version=${version} /
-  dependency groupId=com.yammer.metrics artifactId=metrics-core 
version=2.0.3 /
+  dependency groupId=com.yammer.metrics artifactId=metrics-core 
version=2.2.0 /
   dependency groupId=edu.stanford.ppl artifactId=snaptree 
version=0.1 /
   dependency groupId=org.mindrot artifactId=jbcrypt 
version=0.3m /
   dependency groupId=io.netty artifactId=netty 
version=3.6.6.Final /

[jira] [Commented] (CASSANDRA-5947) Sampling bug in metrics-core-2.0.3.jar used by Cassandra

[
https://issues.apache.org/jira/browse/CASSANDRA-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759181#comment-13759181
]

Jonathan Ellis commented on CASSANDRA-5947:
---

bq. you forget to update build.xml

fixed.

Sampling bug in metrics-core-2.0.3.jar used by Cassandra

Key: CASSANDRA-5947
URL: https://issues.apache.org/jira/browse/CASSANDRA-5947
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: J.B. Langston
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 1.2.10, 2.0.1

There is a sampling bug in the version of the metrics library we're using in
Cassandra. See https://github.com/codahale/metrics/issues/421.
ExponentiallyDecayingSample is used by the Timer's histogram that is used in
stress tool, and according to [~brandon.williams] it is also in a few other
places like the dynamic snitch. The statistical theory involved in this bug
goes over my head so i'm not sure if this would bug would meaningfully affect
its usage by Cassandra. One of the comments on the bug mentions that it
affects slow sampling rates (10 samples/min was the example given). We're
currently distributing metrics-core-2.0.3.jar and according to the release
nodes, this bug is fixed in 2.1.3:
http://metrics.codahale.com/about/release-notes/#v2-1-3-aug-06-2012

[jira] [Commented] (CASSANDRA-5104) new nodes should not attempt to bootstrap and stream until entire cluster is on the same major version


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759188#comment-13759188
 ] 

Yuki Morishita commented on CASSANDRA-5104:
---

Now we have CASSANDRA-5772 in 2.0.0, can we 'won't fix this?

 new nodes should not attempt to bootstrap and stream until entire cluster is 
 on the same major version
 --

 Key: CASSANDRA-5104
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5104
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Michael Kjellman
Assignee: Yuki Morishita
Priority: Minor
 Fix For: 2.0.1


 current behavior for bootstrapping nodes is for an exception to be thrown 
 while a node attempts to stream from another node that has not had 
 upgradesstables run yet.
 A node should not attempt to bootstrap into the cluster until the entire 
 cluster is on the same major version and upgradesstables has already been run 
 on every node in the ring.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5947) Sampling bug in metrics-core-2.0.3.jar used by Cassandra

2013-09-05 Thread Chris Burroughs (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759169#comment-13759169
 ] 

Chris Burroughs commented on CASSANDRA-5947:


Obligatory you forget to update build.xml.

One thing that might be worth noting is that this introduces annoying quoting 
in jconsole 
https://github.com/codahale/metrics/commit/e2336060816ad339676c0e162359c17381ded99f
  so it's

{noformat}
org.apache.cassandra.metrics
{noformat}

instead of 

{noformat}
org.apache.cassandra.metrics
{noformat}

But unless there is some JMX voodoo I'm missing I think that's just a cosmetic 
issue.  cc [~yukim]

 Sampling bug in metrics-core-2.0.3.jar used by Cassandra
 

 Key: CASSANDRA-5947
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5947
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: J.B. Langston
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 1.2.10, 2.0.1


 There is a sampling bug in the version of the metrics library we're using in 
 Cassandra. See https://github.com/codahale/metrics/issues/421. 
 ExponentiallyDecayingSample is used by the Timer's histogram that is used in 
 stress tool, and according to [~brandon.williams] it is also in a few other 
 places like the dynamic snitch. The statistical theory involved in this bug 
 goes over my head so i'm not sure if this would bug would meaningfully affect 
 its usage by Cassandra.  One of the comments on the bug mentions that it 
 affects slow sampling rates (10 samples/min was the example given).  We're 
 currently distributing metrics-core-2.0.3.jar and according to the release 
 nodes, this bug is fixed in 2.1.3: 
 http://metrics.codahale.com/about/release-notes/#v2-1-3-aug-06-2012

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (CASSANDRA-4757) Expose bulk loading progress/status over jmx


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yuki Morishita reopened CASSANDRA-4757:
---


bq. we still don't have a way to associate a call to sstableloader/bulkload 
with a specific streaming session right?

Nick, you are right. I reopen for it.


 Expose bulk loading progress/status over jmx
 

 Key: CASSANDRA-4757
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4757
 Project: Cassandra
  Issue Type: Improvement
Reporter: Nick Bailey
Assignee: Greg DeAngelis
Priority: Minor
  Labels: lhf
 Fix For: 2.0

 Attachments: CASSANDRA-4757.txt, CASSANDRA-4757v2.txt


 The bulk loading interface should be exposing some progress or status 
 information over jmx. This shouldn't be too difficult and should be exposed 
 in a way that the information is available whether you are using the separate 
 sstableloader utility or calling the bulkload jmx call.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5234) Table created through CQL3 are not accessble to Pig 0.10

2013-09-05 Thread Jacques Lemire (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759299#comment-13759299
 ] 

Jacques Lemire commented on CASSANDRA-5234:
---

The last patch for counters to AbstractCassandraStorage.java has not been 
applied either to cassandra-1.2 or to the trunk. Consequently, the problem 
still exists in 1.2.9, as I could verify myself today. I found another recent 
bug report on SO for the same problem: 
http://stackoverflow.com/questions/18553230/error-with-cassandra-pig-cql-counter-column.

Should I open a new bug report for the counters bug even though we have a 
working patch or will you reopen the current issue?

 Table created through CQL3 are not accessble to Pig 0.10
 

 Key: CASSANDRA-5234
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5234
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Affects Versions: 1.2.1
 Environment: Red hat linux 5
Reporter: Shamim Ahmed
Assignee: Alex Liu
 Fix For: 1.2.7

 Attachments: 5234-1-1.2-patch.txt, 5234-1.2-patch.txt, 
 5234-2-1.2branch.txt, 5234-3-1.2branch.txt, 5234-3-trunk.txt, 5234.tx, 
 fix_where_clause.patch, pigCounter-patch.txt


 Hi,
   i have faced a bug when creating table through CQL3 and trying to load data 
 through pig 0.10 as follows:
 java.lang.RuntimeException: Column family 'abc' not found in keyspace 'XYZ'
   at 
 org.apache.cassandra.hadoop.pig.CassandraStorage.initSchema(CassandraStorage.java:1112)
   at 
 org.apache.cassandra.hadoop.pig.CassandraStorage.setLocation(CassandraStorage.java:615).
 This effects from Simple table to table with compound key. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5078) save compaction merge counts in a system table


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759336#comment-13759336
 ] 

Yuki Morishita commented on CASSANDRA-5078:
---

Thanks for the update.
One more thing that worries me is we have a chance to have conflict on the 
entry, since we can have same timestamp among compaction threads.
I suggest using just one timeuuid as primary key. Thoughts?

 save compaction merge counts in a system table
 --

 Key: CASSANDRA-5078
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5078
 Project: Cassandra
  Issue Type: Improvement
Reporter: Matthew F. Dennis
Assignee: lantao yan
Priority: Minor
  Labels: lhf
 Attachments: 5078-v3.txt, 5078-v4.txt, patch1.patch


 we should save the compaction merge stats from CASSANDRA-4894 in the system 
 table and probably expose them via JMX (and nodetool)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5883) Switch to Logback


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yuki Morishita updated CASSANDRA-5883:
--

Attachment: 0001-Additional-migration-to-logback.patch

[~mkjellman] I think we'd better have separate setting for server and tools as 
before, otherwise logback picks up default logback.xml for all tools.

Attaching patch for that.

 Switch to Logback
 -

 Key: CASSANDRA-5883
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5883
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tools
Reporter: Jonathan Ellis
Assignee: Dave Brosius
Priority: Minor
 Fix For: 2.1

 Attachments: 0001-Additional-migration-to-logback.patch, 5883-1.txt, 
 5883-additional1.txt, 5883.txt


 Logback has a number of advantages over log4j, and switching will be 
 straightforward since we are already using the slf4j translation layer: 
 http://logback.qos.ch/reasonsToSwitch.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5883) Switch to Logback

2013-09-05 Thread Michael Kjellman (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759378#comment-13759378
 ] 

Michael Kjellman commented on CASSANDRA-5883:
-

[~yukim] funny, after i attached the patch i was thinking something similar to 
what you did was better. I'm also thinking that maybe the ccm patch i did to 
fix 2.1 should use logback-test.xml, but not sure if we want to get that tied 
into the logback mentality.. 

 Switch to Logback
 -

 Key: CASSANDRA-5883
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5883
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tools
Reporter: Jonathan Ellis
Assignee: Dave Brosius
Priority: Minor
 Fix For: 2.1

 Attachments: 0001-Additional-migration-to-logback.patch, 5883-1.txt, 
 5883-additional1.txt, 5883.txt


 Logback has a number of advantages over log4j, and switching will be 
 straightforward since we are already using the slf4j translation layer: 
 http://logback.qos.ch/reasonsToSwitch.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5858) Add a shuffle dtest

2013-09-05 Thread Ryan McGuire (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McGuire updated CASSANDRA-5858:


Issue Type: Test  (was: Task)

 Add a shuffle dtest
 ---

 Key: CASSANDRA-5858
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5858
 Project: Cassandra
  Issue Type: Test
  Components: Tests
Reporter: Jonathan Ellis
Assignee: Daniel Meyer
Priority: Minor



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-5979) HintedHandOffManager task triggering java.util.NoSuchElementException

2013-09-05 Thread Ravi Prasad (JIRA)

Ravi Prasad created CASSANDRA-5979:
--

 Summary: HintedHandOffManager task triggering 
java.util.NoSuchElementException
 Key: CASSANDRA-5979
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5979
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Ravi Prasad


Seeing this exception every 10 minutes, whenever scheduled HintedHandoff task 
runs:

ERROR [OptionalTasks:1] 2013-09-05 20:48:00,334 CassandraDaemon.java (line 192) 
Exception in thread Thread[OptionalTasks:1,5,main]
java.util.NoSuchElementException
at 
com.google.common.collect.EmptyImmutableSortedSet.last(EmptyImmutableSortedSet.java:100)
at 
org.apache.cassandra.db.columniterator.SSTableNamesIterator.readSimpleColumns(SSTableNamesIterator.java:186)
at 
org.apache.cassandra.db.columniterator.SSTableNamesIterator.read(SSTableNamesIterator.java:156)
at 
org.apache.cassandra.db.columniterator.SSTableNamesIterator.init(SSTableNamesIterator.java:83)
at 
org.apache.cassandra.db.filter.NamesQueryFilter.getSSTableColumnIterator(NamesQueryFilter.java:86)
at 
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:75)
at 
org.apache.cassandra.io.sstable.SSTableScanner$FilteredKeyScanningIterator$1.create(SSTableScanner.java:248)
at 
org.apache.cassandra.db.columniterator.LazyColumnIterator.getSubIterator(LazyColumnIterator.java:75)
at 
org.apache.cassandra.db.columniterator.LazyColumnIterator.getColumnFamily(LazyColumnIterator.java:87)
at 
org.apache.cassandra.db.RowIteratorFactory$2.reduce(RowIteratorFactory.java:95)
at 
org.apache.cassandra.db.RowIteratorFactory$2.reduce(RowIteratorFactory.java:79)
at 
org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:111)
at 
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:97)
at 
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at 
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at 
org.apache.cassandra.db.ColumnFamilyStore$6.computeNext(ColumnFamilyStore.java:1433)
at 
org.apache.cassandra.db.ColumnFamilyStore$6.computeNext(ColumnFamilyStore.java:1429)
at 
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at 
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at 
org.apache.cassandra.db.ColumnFamilyStore.filter(ColumnFamilyStore.java:1500)
at 
org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1477)
at 
org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1472)
at 
org.apache.cassandra.db.HintedHandOffManager.scheduleAllDeliveries(HintedHandOffManager.java:464)
at 
org.apache.cassandra.db.HintedHandOffManager.access$000(HintedHandOffManager.java:90)
at 
org.apache.cassandra.db.HintedHandOffManager$1.run(HintedHandOffManager.java:133)
at 
org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:75)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at 
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

this seems to be a regression from 
https://issues.apache.org/jira/browse/CASSANDRA-5966. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[6/6] git commit: Merge branch 'cassandra-2.0' into trunk

Merge branch 'cassandra-2.0' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a6f03617
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a6f03617
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a6f03617

Branch: refs/heads/trunk
Commit: a6f03617860453f7658980f3f11d6f448c163f31
Parents: a9005cb 85be04b
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Sep 5 11:04:42 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Sep 5 11:04:42 2013 -0500

--

--

[5/6] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

Merge branch 'cassandra-1.2' into cassandra-2.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/85be04bb
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/85be04bb
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/85be04bb

Branch: refs/heads/cassandra-2.0
Commit: 85be04bb207826ad8098b1dd5aaf625694fad3c2
Parents: 1267116 3d9c3dd
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Sep 5 11:04:33 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Sep 5 11:04:33 2013 -0500

--

--

[4/6] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

Merge branch 'cassandra-1.2' into cassandra-2.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/85be04bb
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/85be04bb
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/85be04bb

Branch: refs/heads/trunk
Commit: 85be04bb207826ad8098b1dd5aaf625694fad3c2
Parents: 1267116 3d9c3dd
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Sep 5 11:04:33 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Sep 5 11:04:33 2013 -0500

--

--

[3/6] git commit: update build.xml for metrics-core 2.2.0

update build.xml for metrics-core 2.2.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3d9c3dd3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3d9c3dd3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3d9c3dd3

Branch: refs/heads/trunk
Commit: 3d9c3dd3afe2627eac49db7cfd0764b9e3ef857e
Parents: 1f68442
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Sep 5 11:04:20 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Sep 5 11:04:26 2013 -0500

--
 build.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3d9c3dd3/build.xml
--
diff --git a/build.xml b/build.xml
index 9e1de8d..122759c 100644
--- a/build.xml
+++ b/build.xml
@@ -383,7 +383,7 @@
   dependency groupId=log4j artifactId=log4j version=1.2.16 /
   dependency groupId=org.apache.cassandra 
artifactId=cassandra-all version=${version} /
   dependency groupId=org.apache.cassandra 
artifactId=cassandra-thrift version=${version} /
-  dependency groupId=com.yammer.metrics artifactId=metrics-core 
version=2.0.3 /
+  dependency groupId=com.yammer.metrics artifactId=metrics-core 
version=2.2.0 /
   dependency groupId=edu.stanford.ppl artifactId=snaptree 
version=0.1 /
   dependency groupId=org.mindrot artifactId=jbcrypt 
version=0.3m /
   dependency groupId=io.netty artifactId=netty 
version=3.6.6.Final /

[2/6] git commit: update build.xml for metrics-core 2.2.0

update build.xml for metrics-core 2.2.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3d9c3dd3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3d9c3dd3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3d9c3dd3

Branch: refs/heads/cassandra-2.0
Commit: 3d9c3dd3afe2627eac49db7cfd0764b9e3ef857e
Parents: 1f68442
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Sep 5 11:04:20 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Sep 5 11:04:26 2013 -0500

--
 build.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3d9c3dd3/build.xml
--
diff --git a/build.xml b/build.xml
index 9e1de8d..122759c 100644
--- a/build.xml
+++ b/build.xml
@@ -383,7 +383,7 @@
   dependency groupId=log4j artifactId=log4j version=1.2.16 /
   dependency groupId=org.apache.cassandra 
artifactId=cassandra-all version=${version} /
   dependency groupId=org.apache.cassandra 
artifactId=cassandra-thrift version=${version} /
-  dependency groupId=com.yammer.metrics artifactId=metrics-core 
version=2.0.3 /
+  dependency groupId=com.yammer.metrics artifactId=metrics-core 
version=2.2.0 /
   dependency groupId=edu.stanford.ppl artifactId=snaptree 
version=0.1 /
   dependency groupId=org.mindrot artifactId=jbcrypt 
version=0.3m /
   dependency groupId=io.netty artifactId=netty 
version=3.6.6.Final /

[jira] [Created] (CASSANDRA-5980) Allow cache keys-to-save to be dynamically set

2013-09-05 Thread Chris Burroughs (JIRA)

Chris Burroughs created CASSANDRA-5980:
--

 Summary: Allow cache keys-to-save to be dynamically set
 Key: CASSANDRA-5980
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5980
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Chris Burroughs
Assignee: Chris Burroughs
Priority: Minor


We have the option {key,row}_cache_keys_to_save so that operators can chose a 
balance between can't handle load on cold start and takes too long to 
reboot.  However, this can currently only be set at startup.  This means that 
once it has been determined that X is a bad value for keys_to_save another 
badness inducing restart is required to change X.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5980) Allow cache keys-to-save to be dynamically set

2013-09-05 Thread Chris Burroughs (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Burroughs updated CASSANDRA-5980:
---

Attachment: j5980-a.txt

 * Adds getters/setters for *CacheKeysToSave
 * Dynamic mbean stuff, with scheduling patterned off of changing the cache 
save period
 * setcachekeystosave nodetool command

 Allow cache keys-to-save to be dynamically set
 --

 Key: CASSANDRA-5980
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5980
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Chris Burroughs
Assignee: Chris Burroughs
Priority: Minor
 Attachments: j5980-a.txt


 We have the option {key,row}_cache_keys_to_save so that operators can chose a 
 balance between can't handle load on cold start and takes too long to 
 reboot.  However, this can currently only be set at startup.  This means 
 that once it has been determined that X is a bad value for keys_to_save 
 another badness inducing restart is required to change X.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5966) Average name query performance much worse for wide rows

2013-09-05 Thread Ravi Prasad (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759531#comment-13759531
 ] 

Ravi Prasad commented on CASSANDRA-5966:


This seems to be breaking HintedHandOffManager scheduled task, which does a 
empty names column filter: https://issues.apache.org/jira/browse/CASSANDRA-5979

 Average name query performance much worse for wide rows
 ---

 Key: CASSANDRA-5966
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5966
 Project: Cassandra
  Issue Type: Bug
Reporter: Rick Branson
Assignee: Rick Branson
 Fix For: 1.2.10, 2.0.1

 Attachments: 5966-trunk.txt, 5966.txt, 5966-v2.txt


 The average performance for by-name queries degrades heavily on wide rows. 
 This is because in the wide row case SSTableNamesIterator deserializes every 
 column in the entire row chunk (64KB by default), where-as in the narrow row 
 case, it stops deserializing as soon as it's found the columns it's looking 
 for.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Cassandra Wiki] Update of FAQ by JonathanEllis

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The FAQ page has been changed by JonathanEllis:
https://wiki.apache.org/cassandra/FAQ?action=diffrev1=160rev2=161

Comment:
add clocktie FAQ

   * [[#dropped_messages|Why do I see ... messages dropped.. in the logs?]]
   * [[#cli_keys|Why does the 0.8 cli not assume keys are strings anymore?]]
   * [[#memlock|Cassandra dies with java.lang.OutOfMemoryError: Map failed]]
-  * [[#opp|Why should I avoid order-preserving partitioners]]
+  * [[#opp|Why should I avoid order-preserving partitioners?]]
+  * [[#clocktie|What happens if two updates are made with the same timestamp?]]
  
  Anchor(cant_listen_on_ip_any)
  
@@ -512, +513 @@

  == Why should I avoid order-preserving partitioners? ==
  See [Partitioners].
  
+ Anchor(clocktie)
+ == What happens if two updates are made with the same timestamp? ==
+ 
+ Updates must be commutative, since they may arrive in different orders on 
different replicas.  Thus, in the case of a timestamp tie, Cassandra follows 
two rules: first, deletes take precedence over inserts/updates.  Second, if 
there are two updates, the one with the lexically larger value is selected.
+

[jira] [Reopened] (CASSANDRA-5816) [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp

2013-09-05 Thread Blair Zajac (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blair Zajac reopened CASSANDRA-5816:


Reproduced In: 2.0
Since Version: 2.0

Looking at DataStax's 2.0.0 Debian packages, the change didn't make its way in.

Digging deeper, it's only on the cassandra-1.2 branch.  Can someone 
merge/cherry-pick it to cassandra-2.0 and trunk.

Thanks,
Blair


 [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
 ---

 Key: CASSANDRA-5816
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5816
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Affects Versions: 1.2.7
Reporter: Blair Zajac
Assignee: Blair Zajac
Priority: Minor
 Fix For: 1.2.9, 2.0 rc1


 I'm switching my Ubuntu servers running Cassandra from ntp to chrony for the 
 reasons cited here when Fedora made the switch to have chrony be the default 
 NTP client:
 http://fedoraproject.org/wiki/Features/ChronyDefaultNTP
 Currently, the debian packaging recommends only ntp so if chrony is installed 
 it'll want to remove it and install ntp.  I also added ptpd, the Precision 
 Time Protocol daemon, which is another time syncing server for completeness.
 Please apply this to the 1.2 branch so the next 1.2.x release can deploy with 
 chrony.
 Below is the patch since it's a one-liner.
 Thanks,
 Blair
 --- a/debian/control
 +++ b/debian/control
 @@ -12,7 +12,7 @@ Standards-Version: 3.8.3
  Package: cassandra
  Architecture: all
  Depends: openjdk-6-jre-headless (= 6b11) | java6-runtime, jsvc (= 1.0), 
 libcommons-daemon-java (= 1.0), adduser, libjna-java, python (= 2.5), 
 python-support (= 0.90.0), ${misc:Depends}
 -Recommends: ntp
 +Recommends: chrony | ntp | ptpd
  Conflicts: apache-cassandra1
  Replaces: apache-cassandra1
  Description: distributed storage system for structured data

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[2/3] git commit: cherry-pick CASSANDRA-5816

cherry-pick CASSANDRA-5816


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ad6f00af
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ad6f00af
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ad6f00af

Branch: refs/heads/trunk
Commit: ad6f00afaa6a00f5fa1ce0bf832d18a623531969
Parents: 85be04b
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue Jul 30 15:57:45 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Sep 5 21:12:12 2013 -0500

--
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ad6f00af/debian/control
--
diff --git a/debian/control b/debian/control
index bdee7df..631c60b 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Standards-Version: 3.8.3
 Package: cassandra
 Architecture: all
 Depends: openjdk-7-jre-headless | java7-runtime, adduser, libjna-java, python 
(= 2.5), python-support (= 0.90.0), ${misc:Depends}
-Recommends: ntp
+Recommends: ntp | time-daemon
 Conflicts: apache-cassandra1
 Replaces: apache-cassandra1
 Description: distributed storage system for structured data

[3/3] git commit: Merge branch 'cassandra-2.0' into trunk

Merge branch 'cassandra-2.0' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/cfe926ac
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/cfe926ac
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/cfe926ac

Branch: refs/heads/trunk
Commit: cfe926ac6a3c230c1670ee32bc4e9a99978f532c
Parents: a6f0361 ad6f00a
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Sep 5 21:12:47 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Sep 5 21:12:47 2013 -0500

--
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--

[1/3] git commit: cherry-pick CASSANDRA-5816

Updated Branches:
  refs/heads/cassandra-2.0 85be04bb2 - ad6f00afa
  refs/heads/trunk a6f036178 - cfe926ac6


cherry-pick CASSANDRA-5816


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ad6f00af
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ad6f00af
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ad6f00af

Branch: refs/heads/cassandra-2.0
Commit: ad6f00afaa6a00f5fa1ce0bf832d18a623531969
Parents: 85be04b
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue Jul 30 15:57:45 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Sep 5 21:12:12 2013 -0500

--
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ad6f00af/debian/control
--
diff --git a/debian/control b/debian/control
index bdee7df..631c60b 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Standards-Version: 3.8.3
 Package: cassandra
 Architecture: all
 Depends: openjdk-7-jre-headless | java7-runtime, adduser, libjna-java, python 
(= 2.5), python-support (= 0.90.0), ${misc:Depends}
-Recommends: ntp
+Recommends: ntp | time-daemon
 Conflicts: apache-cassandra1
 Replaces: apache-cassandra1
 Description: distributed storage system for structured data

[jira] [Updated] (CASSANDRA-5816) [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-5816:
--

Fix Version/s: (was: 2.0 rc1)
   2.0.1

Done.  Sorry about the mix up!

 [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
 ---

 Key: CASSANDRA-5816
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5816
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Affects Versions: 1.2.7
Reporter: Blair Zajac
Assignee: Blair Zajac
Priority: Minor
 Fix For: 1.2.9, 2.0.1


 I'm switching my Ubuntu servers running Cassandra from ntp to chrony for the 
 reasons cited here when Fedora made the switch to have chrony be the default 
 NTP client:
 http://fedoraproject.org/wiki/Features/ChronyDefaultNTP
 Currently, the debian packaging recommends only ntp so if chrony is installed 
 it'll want to remove it and install ntp.  I also added ptpd, the Precision 
 Time Protocol daemon, which is another time syncing server for completeness.
 Please apply this to the 1.2 branch so the next 1.2.x release can deploy with 
 chrony.
 Below is the patch since it's a one-liner.
 Thanks,
 Blair
 --- a/debian/control
 +++ b/debian/control
 @@ -12,7 +12,7 @@ Standards-Version: 3.8.3
  Package: cassandra
  Architecture: all
  Depends: openjdk-6-jre-headless (= 6b11) | java6-runtime, jsvc (= 1.0), 
 libcommons-daemon-java (= 1.0), adduser, libjna-java, python (= 2.5), 
 python-support (= 0.90.0), ${misc:Depends}
 -Recommends: ntp
 +Recommends: chrony | ntp | ptpd
  Conflicts: apache-cassandra1
  Replaces: apache-cassandra1
  Description: distributed storage system for structured data

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Cassandra Wiki] Trivial Update of FAQ by JonathanEllis

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The FAQ page has been changed by JonathanEllis:
https://wiki.apache.org/cassandra/FAQ?action=diffrev1=161rev2=162

  Anchor(clocktie)
  == What happens if two updates are made with the same timestamp? ==
  
- Updates must be commutative, since they may arrive in different orders on 
different replicas.  Thus, in the case of a timestamp tie, Cassandra follows 
two rules: first, deletes take precedence over inserts/updates.  Second, if 
there are two updates, the one with the lexically larger value is selected.
+ Updates must be commutative, since they may arrive in different orders on 
different replicas.  As long as Cassandra has a deterministic way to pick the 
winner, the one selected is as valid as any other, and the specifics should be 
treated as an implementation detail.  That said, in the case of a timestamp 
tie, Cassandra follows two rules: first, deletes take precedence over 
inserts/updates.  Second, if there are two updates, the one with the lexically 
larger value is selected.

[jira] [Commented] (CASSANDRA-5816) [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp

2013-09-05 Thread Blair Zajac (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759778#comment-13759778
 ] 

Blair Zajac commented on CASSANDRA-5816:


No problem. Thank you!

 [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
 ---

 Key: CASSANDRA-5816
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5816
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Affects Versions: 1.2.7
Reporter: Blair Zajac
Assignee: Blair Zajac
Priority: Minor
 Fix For: 1.2.9, 2.0.1


 I'm switching my Ubuntu servers running Cassandra from ntp to chrony for the 
 reasons cited here when Fedora made the switch to have chrony be the default 
 NTP client:
 http://fedoraproject.org/wiki/Features/ChronyDefaultNTP
 Currently, the debian packaging recommends only ntp so if chrony is installed 
 it'll want to remove it and install ntp.  I also added ptpd, the Precision 
 Time Protocol daemon, which is another time syncing server for completeness.
 Please apply this to the 1.2 branch so the next 1.2.x release can deploy with 
 chrony.
 Below is the patch since it's a one-liner.
 Thanks,
 Blair
 --- a/debian/control
 +++ b/debian/control
 @@ -12,7 +12,7 @@ Standards-Version: 3.8.3
  Package: cassandra
  Architecture: all
  Depends: openjdk-6-jre-headless (= 6b11) | java6-runtime, jsvc (= 1.0), 
 libcommons-daemon-java (= 1.0), adduser, libjna-java, python (= 2.5), 
 python-support (= 0.90.0), ${misc:Depends}
 -Recommends: ntp
 +Recommends: chrony | ntp | ptpd
  Conflicts: apache-cassandra1
  Replaces: apache-cassandra1
  Description: distributed storage system for structured data

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Cassandra Wiki] Update of MemtableThresholds by JonathanEllis

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The MemtableThresholds page has been changed by JonathanEllis:
https://wiki.apache.org/cassandra/MemtableThresholds?action=diffrev1=22rev2=23

+ == This document applies to pre-1.0 versions of Cassandra. ==
+ See 
[[http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-improved-memory-and-disk-space-management|this
 article]] for how Cassandra 1.0 automatically manages memory for you.
+ 
  TableOfContents
  
  == Don't Touch that Dial ==

[Cassandra Wiki] Update of ExtensibleAuth by JonathanEllis

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The ExtensibleAuth page has been changed by JonathanEllis:
https://wiki.apache.org/cassandra/ExtensibleAuth?action=diffrev1=3rev2=4

- == Cassandra's Extensible Authentication/Authorization ==
+ TODO: update this in light of 
http://www.planetcassandra.org/blog/post/a-quick-tour-of-internal-authentication-and-authorization-security-in-datastax-enterprise-and-apache-cassandra
  
- Cassandra uses an extensible authentication/authorization mechanism found in 
the org.apache.cassandra.auth Java source package.  It is configured in 
conf/storage-conf.xml (0.6.x) and conf/cassandra.yaml (0.7+).  0.6 uses the 
`IAuthenticator` interface to provide both authentication and authorization, 
but 0.7 splits the interface into `IAuthenticator` to provide authentication, 
and `IAuthority` to provide authorization.
- 
- There are two complementary implementations of these interfaces built-in:
- 
-  * The default `AllowAllAuthenticator` (and `AllowAllAuthority` in 0.7) 
approach is essentially pass-through.
-  * `SimpleAuthenticator` (and `SimpleAuthority` in 0.7) is property file 
based (using passwd.properties and access.properties).  For more information on 
this approach, see the source in org.apache.cassandra.auth. In 0.7, the format 
of the access.properties configuration is slightly different.
- 
- Both of the built-in options implement `IAuthenticator` (and `IAuthority` in 
0.7).  Those wanting custom auth implementations can start there.
-

[Cassandra Wiki] Update of FAQ by JonathanEllis