[jira] [Commented] (CASSANDRA-10085) Allow BATCH with conditions to span multiple tables with same partition key

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10085:
--

I will simply start by noting that doing this is not trivial considering the 
current implementation since everything Paxos related is currently grouped by 
cfId. And while changing that is not too complex in itself, dealing with 
backward compatibility is (as always) more painful. And of course, doing so 
would also potentially create contention between tables, which would be desired 
in your case but might be detrimental in other cases, so we'd have to debate 
whether that's acceptable (of if we make it an option, which adds complexity to 
the system).

I'll also note that:
# conditionals are currently pretty costly in C* and should be used sparingly.
# your justification for this sounds like you're trying to translate as 
directly as possible what do in SQL DBs into C*. That's rarely the right 
approach.
That said, JIRA is not the right place to discuss modeling options so I could 
maybe encourage you to start by sending a mail on the mailing list asking 
others how they usually deal with the kind of issue you're trying to deal with. 
You might get satisfying answers.

But to manage expectation, given the technical difficulties above and the fact 
that we're not as convinced as you are that this is crucial (if we were, we 
would have designed it to allow it in the first place), I would expect this to 
be dealt with in the short term.

Which is not to say that this wouldn't be a nice to have all other things 
considered.

 Allow BATCH with conditions to span multiple tables with same partition key
 ---

 Key: CASSANDRA-10085
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10085
 Project: Cassandra
  Issue Type: Improvement
Reporter: Dennis Roppelt
  Labels: batch, conditional-statement, partitioning

 h4. Use case:
 I want to use batch to keep data between tables synchronized with help of 
 conditionals. In particular, I want to have a ONE-to-ONE relationship in my 
 data model. I dont want to have an unintended upsert while trying to maintain 
 a consistent one-to-one relationship (write requests from other clients that 
 try to create a different relationship with one of the keys I inteded to 
 use), which is why I would like the IF NOT EXISTS when inserting data into 
 multiple tables in a batch.
 But when trying to insert data in a batch-block with an IF NOT EXISTS, I get 
 the following response (reproduceable example further below):
 {code}
 cqlsh:testkeyspace 
 BEGIN BATCH 
 INSERT INTO key1_to_key2 (partKey, key1, key2) values (1,2,3) IF NOT EXISTS; 
 INSERT INTO key2_to_key1 (partKey, key1, key2) values (1,2,3) IF NOT EXISTS; 
 APPLY BATCH;
 Bad Request: Batch with conditions cannot span multiple tables{code}
 The tables have a primary key on (partKey, key1) and (partKey, key2). Which 
 means that partKey in both cases is their partition key. Which in the example 
 also is the same value.
 h4. Why I want to use a BATCH-statement that way:
 In traditional databases, to design a one-to-one relationship, I would create 
 one table with two keys, both with a unique constraint:
 {code:sql}
 CREATE TABLE  `myOneToOneTable` (
   `ID` int NOT NULL,
   `KEY_ONE` int NOT NULL,
   `KEY_TWO` int NOT NULL,
 // some other fields
   PRIMARY KEY (`ID`),
   UNIQUE KEY `KEY_ONE`,
   UNIQUE KEY `KEY_TWO`
 );
 {code}
 (simplified example taken from an [one-to-one example for 
 mysql|http://www.mkyong.com/mysql/how-to-define-one-to-one-relationship-in-mysql/])
 As far as I know, unique constraints are not supported in Cassandra, so 
 another way around it would be to maintain the relationshipt between two 
 tables, each sharing the same partition key. For which I would like Cassandra 
 to make sure that when I insert data, either both are inserted at the same 
 time or none (to prevent other writing client to insert a different 
 one-to-one relationship than me). 
 [According to the documentation, this is what BATCH-Statements are used 
 for|http://docs.datastax.com/en/cql/3.3/cql/cql_using/useBatch.html]
 {quote}
 Instead, using batches to synchronize data to tables is a legitimate 
 operation. 
 {quote}
 I expected it to be able to do it, but as seen above, I cannot enforce INSERT 
 IF NOT EXISTS over multiple tables.
 I do understand the background as to *why* there is a limitation coded that 
 way, so that not too many nodes have to take part in processing of the batch. 
 However, if the operations use
 # primary keys in their statements for each table
 # all primary keys contain the same value, thus resulting in the same hash 
 for partioning
 # tables belong to the same keyspace
 the batch 

[jira] [Assigned] (CASSANDRA-9312) Provide a way to retrieve the write time of a CQL row

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne reassigned CASSANDRA-9312:
---

Assignee: Sylvain Lebresne

 Provide a way to retrieve the write time of a CQL row
 -

 Key: CASSANDRA-9312
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9312
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Nicolas Favre-Felix
Assignee: Sylvain Lebresne
 Fix For: 2.2.x


 There is currently no way to retrieve the writetime of a CQL row. This is 
 an issue for tables in which all dimensions are part of the primary key.
 Since Cassandra already stores a cell for the CQL row, it would make sense to 
 provide a way to read its timestamp. This feature would be consistent with 
 the concept of a row as an entity containing a number of optional columns, 
 but able to exist on its own.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[1/3] cassandra git commit: Fix typo in CREATE TABLE error message

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 793bf45fb - c41412a7f


Fix typo in CREATE TABLE error message

patch by sehrope; reviewed by slebresne for CASSANDRA-10087


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

Branch: refs/heads/trunk
Commit: 0f287c46fc87032c82bd53be11a13f2780b35593
Parents: c645b11
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Sun Aug 16 12:15:20 2015 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Sun Aug 16 12:15:20 2015 +0200

--
 .../org/apache/cassandra/cql3/statements/CreateTableStatement.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0f287c46/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
index b3591a2..7810a8a 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
@@ -221,7 +221,7 @@ public class CreateTableStatement extends 
SchemaAlteringStatement
 {
 // Column family name
 if (!columnFamily().matches(\\w+))
-throw new InvalidRequestException(String.format(\%s\ is not 
a valid table name (must be alphanumeric character only: [0-9A-Za-z]+), 
columnFamily()));
+throw new InvalidRequestException(String.format(\%s\ is not 
a valid table name (must be alphanumeric character or underscore only: 
[a-zA-Z_0-9]+), columnFamily()));
 if (columnFamily().length()  Schema.NAME_LENGTH)
 throw new InvalidRequestException(String.format(Table names 
shouldn't be more than %s characters long (got \%s\), Schema.NAME_LENGTH, 
columnFamily()));
 

[2/2] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[slebresne]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: fb28cb7b6843adab276f509dc9bdc96713381261
Parents: da8d48a 0f287c4
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Sun Aug 16 12:16:55 2015 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Sun Aug 16 12:16:55 2015 +0200

--
 .../org/apache/cassandra/cql3/statements/CreateTableStatement.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb28cb7b/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
--

cassandra git commit: Fix typo in CREATE TABLE error message

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 c645b1193 - 0f287c46f


Fix typo in CREATE TABLE error message

patch by sehrope; reviewed by slebresne for CASSANDRA-10087


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

Branch: refs/heads/cassandra-2.2
Commit: 0f287c46fc87032c82bd53be11a13f2780b35593
Parents: c645b11
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Sun Aug 16 12:15:20 2015 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Sun Aug 16 12:15:20 2015 +0200

--
 .../org/apache/cassandra/cql3/statements/CreateTableStatement.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0f287c46/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
index b3591a2..7810a8a 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
@@ -221,7 +221,7 @@ public class CreateTableStatement extends 
SchemaAlteringStatement
 {
 // Column family name
 if (!columnFamily().matches(\\w+))
-throw new InvalidRequestException(String.format(\%s\ is not 
a valid table name (must be alphanumeric character only: [0-9A-Za-z]+), 
columnFamily()));
+throw new InvalidRequestException(String.format(\%s\ is not 
a valid table name (must be alphanumeric character or underscore only: 
[a-zA-Z_0-9]+), columnFamily()));
 if (columnFamily().length()  Schema.NAME_LENGTH)
 throw new InvalidRequestException(String.format(Table names 
shouldn't be more than %s characters long (got \%s\), Schema.NAME_LENGTH, 
columnFamily()));
 

[2/3] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[slebresne]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: fb28cb7b6843adab276f509dc9bdc96713381261
Parents: da8d48a 0f287c4
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Sun Aug 16 12:16:55 2015 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Sun Aug 16 12:16:55 2015 +0200

--
 .../org/apache/cassandra/cql3/statements/CreateTableStatement.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb28cb7b/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
--

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

[slebresne]

Merge branch 'cassandra-3.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/c41412a7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c41412a7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c41412a7

Branch: refs/heads/trunk
Commit: c41412a7f9883cd4c3211d1b688dafcc57120777
Parents: 793bf45 fb28cb7
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Sun Aug 16 12:17:16 2015 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Sun Aug 16 12:17:16 2015 +0200

--
 .../org/apache/cassandra/cql3/statements/CreateTableStatement.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--

[1/2] cassandra git commit: Fix typo in CREATE TABLE error message

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 da8d48a79 - fb28cb7b6


Fix typo in CREATE TABLE error message

patch by sehrope; reviewed by slebresne for CASSANDRA-10087


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

Branch: refs/heads/cassandra-3.0
Commit: 0f287c46fc87032c82bd53be11a13f2780b35593
Parents: c645b11
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Sun Aug 16 12:15:20 2015 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Sun Aug 16 12:15:20 2015 +0200

--
 .../org/apache/cassandra/cql3/statements/CreateTableStatement.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0f287c46/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
index b3591a2..7810a8a 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
@@ -221,7 +221,7 @@ public class CreateTableStatement extends 
SchemaAlteringStatement
 {
 // Column family name
 if (!columnFamily().matches(\\w+))
-throw new InvalidRequestException(String.format(\%s\ is not 
a valid table name (must be alphanumeric character only: [0-9A-Za-z]+), 
columnFamily()));
+throw new InvalidRequestException(String.format(\%s\ is not 
a valid table name (must be alphanumeric character or underscore only: 
[a-zA-Z_0-9]+), columnFamily()));
 if (columnFamily().length()  Schema.NAME_LENGTH)
 throw new InvalidRequestException(String.format(Table names 
shouldn't be more than %s characters long (got \%s\), Schema.NAME_LENGTH, 
columnFamily()));
 

[jira] [Comment Edited] (CASSANDRA-10085) Allow BATCH with conditions to span multiple tables with same partition key

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne edited comment on CASSANDRA-10085 at 8/16/15 12:31 PM:


I will simply start by noting that doing this is not trivial considering the 
current implementation since everything Paxos related is currently grouped by 
cfId. And while changing that is not too complex in itself, dealing with 
backward compatibility is (as always) more painful. And of course, doing so 
would also potentially create contention between tables, which would be desired 
in your case but might be detrimental in other cases, so we'd have to debate 
whether that's acceptable (of if we make it an option, which adds complexity to 
the system).

I'll also note that:
# conditionals are currently pretty costly in C* and should be used sparingly.
# your justification for this sounds like you're trying to translate as 
directly as possible what do in SQL DBs into C*. That's rarely the right 
approach.
That said, JIRA is not the right place to discuss modeling options so I could 
maybe encourage you to start by sending a mail on the mailing list asking 
others how they usually deal with the kind of issue you're trying to deal with. 
You might get satisfying answers.

But to manage expectation, given the technical difficulties above and the fact 
that we're not as convinced as you are that this is crucial (if we were, we 
would have designed it to allow it in the first place), I would not expect this 
to be dealt with in the short term.

Which is not to say that this wouldn't be a nice to have all other things 
considered.


was (Author: slebresne):
I will simply start by noting that doing this is not trivial considering the 
current implementation since everything Paxos related is currently grouped by 
cfId. And while changing that is not too complex in itself, dealing with 
backward compatibility is (as always) more painful. And of course, doing so 
would also potentially create contention between tables, which would be desired 
in your case but might be detrimental in other cases, so we'd have to debate 
whether that's acceptable (of if we make it an option, which adds complexity to 
the system).

I'll also note that:
# conditionals are currently pretty costly in C* and should be used sparingly.
# your justification for this sounds like you're trying to translate as 
directly as possible what do in SQL DBs into C*. That's rarely the right 
approach.
That said, JIRA is not the right place to discuss modeling options so I could 
maybe encourage you to start by sending a mail on the mailing list asking 
others how they usually deal with the kind of issue you're trying to deal with. 
You might get satisfying answers.

But to manage expectation, given the technical difficulties above and the fact 
that we're not as convinced as you are that this is crucial (if we were, we 
would have designed it to allow it in the first place), I would expect this to 
be dealt with in the short term.

Which is not to say that this wouldn't be a nice to have all other things 
considered.

 Allow BATCH with conditions to span multiple tables with same partition key
 ---

 Key: CASSANDRA-10085
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10085
 Project: Cassandra
  Issue Type: Improvement
Reporter: Dennis Roppelt
  Labels: batch, conditional-statement, partitioning

 h4. Use case:
 I want to use batch to keep data between tables synchronized with help of 
 conditionals. In particular, I want to have a ONE-to-ONE relationship in my 
 data model. I dont want to have an unintended upsert while trying to maintain 
 a consistent one-to-one relationship (write requests from other clients that 
 try to create a different relationship with one of the keys I inteded to 
 use), which is why I would like the IF NOT EXISTS when inserting data into 
 multiple tables in a batch.
 But when trying to insert data in a batch-block with an IF NOT EXISTS, I get 
 the following response (reproduceable example further below):
 {code}
 cqlsh:testkeyspace 
 BEGIN BATCH 
 INSERT INTO key1_to_key2 (partKey, key1, key2) values (1,2,3) IF NOT EXISTS; 
 INSERT INTO key2_to_key1 (partKey, key1, key2) values (1,2,3) IF NOT EXISTS; 
 APPLY BATCH;
 Bad Request: Batch with conditions cannot span multiple tables{code}
 The tables have a primary key on (partKey, key1) and (partKey, key2). Which 
 means that partKey in both cases is their partition key. Which in the example 
 also is the same value.
 h4. Why I want to use a BATCH-statement that way:
 In traditional databases, to design a one-to-one relationship, I would create 
 one table with two keys, both with a unique constraint:
 

[jira] [Commented] (CASSANDRA-9312) Provide a way to retrieve the write time of a CQL row

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-9312:
-

I'll note that my preference regarding syntax for this is simply to start 
allowing the {{writeTime}} and {{ttl}} methods on primary key columns (it will 
thus return the same value for every PK column of the same row).

The alternative would be to have a special syntax that include all the PK 
columns, like:
{{noformat}}
SELECT writeTime(k, t1, t2), ttl(k, t1, t2) WHERE ...;
{{noformat}}
but it doesn't feel really better to me and is more special-casy and slightly 
more complex from an implementation point of view.

 Provide a way to retrieve the write time of a CQL row
 -

 Key: CASSANDRA-9312
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9312
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Nicolas Favre-Felix
Assignee: Sylvain Lebresne
 Fix For: 2.2.x


 There is currently no way to retrieve the writetime of a CQL row. This is 
 an issue for tables in which all dimensions are part of the primary key.
 Since Cassandra already stores a cell for the CQL row, it would make sense to 
 provide a way to read its timestamp. This feature would be consistent with 
 the concept of a row as an entity containing a number of optional columns, 
 but able to exist on its own.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-9312) Provide a way to retrieve the write time of a CQL row

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-9312:

Fix Version/s: 2.2.x

 Provide a way to retrieve the write time of a CQL row
 -

 Key: CASSANDRA-9312
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9312
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Nicolas Favre-Felix
Assignee: Sylvain Lebresne
 Fix For: 2.2.x


 There is currently no way to retrieve the writetime of a CQL row. This is 
 an issue for tables in which all dimensions are part of the primary key.
 Since Cassandra already stores a cell for the CQL row, it would make sense to 
 provide a way to read its timestamp. This feature would be consistent with 
 the concept of a row as an entity containing a number of optional columns, 
 but able to exist on its own.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9854) Make CompactionController.maybeRefreshOverlaps public

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis commented on CASSANDRA-9854:
---

Is this a subset of CASSANDRA-8671 or a separate need?

 Make CompactionController.maybeRefreshOverlaps public
 -

 Key: CASSANDRA-9854
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9854
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Mike Adamson
Assignee: Mike Adamson
 Fix For: 3.0.0 rc1

 Attachments: 9854.txt


 This method is currently package protected and means that 3rd party 
 compaction strategies outside of the compaction package cannot use it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10086) Add a CLEAR cqlsh command to clear the console

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-10086:
---
Reviewer: Stefania

[~Stefania] to review

 Add a CLEAR cqlsh command to clear the console
 

 Key: CASSANDRA-10086
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10086
 Project: Cassandra
  Issue Type: Improvement
Reporter: Paul O'Fallon
Priority: Trivial
  Labels: cqlsh
 Attachments: 10086.txt


 It would be very helpful to have a CLEAR command to clear the cqlsh 
 console.  I learned (after researching a patch for this) that lowercase 
 CTRL+L will clear the screen, but having a discrete command would make that 
 more obvious.  To match the expectations of Windows users, an alias to CLS 
 would be nice as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-9893) Fix upgrade tests from #9704 that are still failing

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-9893:
--
Assignee: Blake Eggleston  (was: Benjamin Lerer)

 Fix upgrade tests from #9704 that are still failing
 ---

 Key: CASSANDRA-9893
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9893
 Project: Cassandra
  Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Blake Eggleston
 Fix For: 3.0.0 rc1


 The first things to do on this ticket would be to commit Tyler's branch 
 (https://github.com/thobbs/cassandra-dtest/tree/8099-backwards-compat) to the 
 dtests so cassci run them. I've had to do a few minor modifications to have 
 them run locally so someone which access to cassci should do it and make sure 
 it runs properly.
 Once we have that, we should fix any test that isn't passing. I've ran the 
 tests locally and I had 8 failures. for 2 of them, it sounds plausible that 
 they'll get fixed by the patch of CASSANDRA-9775, though that's just a guess. 
  The rest where test that timeouted without a particular error in the log, 
 and running some of them individually, they passed.  So we'll have to see if 
 it's just my machine being overly slow when running them all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-9916) batch_mutate failing on trunk

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-9916:
--
Assignee: Blake Eggleston  (was: Paulo Motta)

 batch_mutate failing on trunk
 -

 Key: CASSANDRA-9916
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9916
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Mike Adamson
Assignee: Blake Eggleston
 Fix For: 3.0.0 rc1


 {{batch_mutate}} is failing on trunk with the following error:
 {noformat}
 java.lang.AssertionError: current = 
 ColumnDefinition{name=b@706172656e745f70617468, 
 type=org.apache.cassandra.db.marshal.BytesType, kind=STATIC, 
 componentIndex=null, indexName=cfs_parent_path, indexType=KEYS}, new = 
 ColumnDefinition{name=b@70617468, 
 type=org.apache.cassandra.db.marshal.BytesType, kind=STATIC, 
 componentIndex=null, indexName=cfs_path, indexType=KEYS}
 at 
 org.apache.cassandra.db.rows.ArrayBackedRow$SortedBuilder.setColumn(ArrayBackedRow.java:617)
 at 
 org.apache.cassandra.db.rows.ArrayBackedRow$SortedBuilder.addCell(ArrayBackedRow.java:630)
 at 
 org.apache.cassandra.db.LegacyLayout$CellGrouper.addCell(LegacyLayout.java:891)
 at 
 org.apache.cassandra.db.LegacyLayout$CellGrouper.addAtom(LegacyLayout.java:843)
 at 
 org.apache.cassandra.db.LegacyLayout.getNextRow(LegacyLayout.java:390)
 at 
 org.apache.cassandra.db.LegacyLayout.toUnfilteredRowIterator(LegacyLayout.java:326)
 at 
 org.apache.cassandra.db.LegacyLayout.toUnfilteredRowIterator(LegacyLayout.java:288)
 at 
 org.apache.cassandra.thrift.CassandraServer.createMutationList(CassandraServer.java:1110)
 at 
 org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:1249)
 {noformat}
 The following mutations was passed to {{batch_mutate}} to get this error
 {noformat}
 mutationMap = {java.nio.HeapByteBuffer[pos=0 lim=32 cap=32]=
 {inode=[
 Mutation(column_or_supercolumn:ColumnOrSuperColumn(column:Column(name:80 62 
 00 04 70 61 74 68 00, value:2F, timestamp:1438165021749))), 
 Mutation(column_or_supercolumn:ColumnOrSuperColumn(column:Column(name:80 62 
 00 0B 70 61 72 65 6E 74 5F 70 61 74 68 00, value:6E 75 6C 6C, 
 timestamp:1438165021749))), 
 Mutation(column_or_supercolumn:ColumnOrSuperColumn(column:Column(name:80 62 
 00 08 73 65 6E 74 69 6E 65 6C 00, value:78, timestamp:1438165021749))), 
 Mutation(column_or_supercolumn:ColumnOrSuperColumn(column:Column(name:80 62 
 00 04 64 61 74 61 00, value:00 00 00 08 64 61 74 61 73 74 61 78 00 00 00 05 
 75 73 65 72 73 01 FF 00 00 00 00 00 04 00 00 00 01, timestamp:1438165021749)))
 ]}}
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-9966) batched CAS statements are not serializable

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-9966:

Issue Type: New Feature  (was: Bug)

 batched CAS statements are not serializable
 ---

 Key: CASSANDRA-9966
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9966
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Sam Overton
Assignee: Sylvain Lebresne
Priority: Critical
 Fix For: 3.x, 2.2.x


 It is possible to batch CAS statements such that their outcome is different 
 to the outcome were they executed sequentially outside of a batch.
 eg.
 a | b | c
 a | 1 | 1
 BEGIN BATCH
 UPDATE foo SET b=2 WHERE a='a' iF c=1
 UPDATE foo SET c=2 WHERE a='a' IF b=1
 APPLY BATCH
 results in 
 a | b | c
 a | 2 | 2
 If these statements were not batched, the outcome would be 
 UPDATE foo SET b=2 WHERE a='a' iF c=1
 a | b | c
 a | 2 | 1
 UPDATE foo SET c=2 WHERE a='a' IF b=1
 applied=false (pre-condition b=1 not met)
 Cassandra already checks for incompatible preconditions within a batch (eg 
 one statement with IF c=1 and another statement with IF c=2). It should also 
 check for mutations to columns in one statement that affect the 
 pre-conditions of another statement, or it should evaluate the statement 
 pre-conditions sequentially after applying the mutations of the previous 
 statement to an in-memory model of the partition.
 For backwards compatibility this would have to be a new strict batch mode, 
 eg.
 BEGIN STRICT BATCH



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-9966) batched CAS statements are not serializable

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-9966:

Priority: Major  (was: Critical)

 batched CAS statements are not serializable
 ---

 Key: CASSANDRA-9966
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9966
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Sam Overton
Assignee: Sylvain Lebresne
 Fix For: 3.x, 2.2.x


 It is possible to batch CAS statements such that their outcome is different 
 to the outcome were they executed sequentially outside of a batch.
 eg.
 a | b | c
 a | 1 | 1
 BEGIN BATCH
 UPDATE foo SET b=2 WHERE a='a' iF c=1
 UPDATE foo SET c=2 WHERE a='a' IF b=1
 APPLY BATCH
 results in 
 a | b | c
 a | 2 | 2
 If these statements were not batched, the outcome would be 
 UPDATE foo SET b=2 WHERE a='a' iF c=1
 a | b | c
 a | 2 | 1
 UPDATE foo SET c=2 WHERE a='a' IF b=1
 applied=false (pre-condition b=1 not met)
 Cassandra already checks for incompatible preconditions within a batch (eg 
 one statement with IF c=1 and another statement with IF c=2). It should also 
 check for mutations to columns in one statement that affect the 
 pre-conditions of another statement, or it should evaluate the statement 
 pre-conditions sequentially after applying the mutations of the previous 
 statement to an in-memory model of the partition.
 For backwards compatibility this would have to be a new strict batch mode, 
 eg.
 BEGIN STRICT BATCH



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9966) batched CAS statements are not serializable

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-9966:
-

I don't think this is a bug in the sense that this is working as designed.

Statements within a batch in CQL are not applied sequentially, they are applied 
all at once (they all get the same timestamp in particular), and in that sense 
it is consistent for CAS one to also work that way (and hence all conditions 
are evaluated on the state the batch is applied to as a whole).

Which is not to say we can't consider as a new feature the ability to have 
statements of a batch applied sequentially. That said, I can see a few points 
worth considering for the addition of such new feature:
* I think we'd have to do 2 things: 1) evaluate the conditions sequentially and 
2) generate increasing timestamps for each statement within the batch (so if 2 
statement update the same column, the result is consistent with a sequential 
application). The latter could work in practice because we guarantee that 2 
conficting CAS operation will have at least a 1ms differences in their 
timestamp, and since timestamp are in micros, we could have up to 1000 
statements within a batch without having a problem, but that still feels a bit 
dodgy in principle (and we'll want to make sure this wouldn't be hard to 
maintain post-CASSANDRA-6246).
* Do we only allow that new form for batches that goes through Paxos? In 
principle, from a user perspective, there would seems to be no reason to have 
such limitation, but the part about bumping the timestamp for each statement 
within the batch feels even more dodgy in the non-Paxos case.

 batched CAS statements are not serializable
 ---

 Key: CASSANDRA-9966
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9966
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Sam Overton
Assignee: Sylvain Lebresne
Priority: Critical
 Fix For: 3.x, 2.2.x


 It is possible to batch CAS statements such that their outcome is different 
 to the outcome were they executed sequentially outside of a batch.
 eg.
 a | b | c
 a | 1 | 1
 BEGIN BATCH
 UPDATE foo SET b=2 WHERE a='a' iF c=1
 UPDATE foo SET c=2 WHERE a='a' IF b=1
 APPLY BATCH
 results in 
 a | b | c
 a | 2 | 2
 If these statements were not batched, the outcome would be 
 UPDATE foo SET b=2 WHERE a='a' iF c=1
 a | b | c
 a | 2 | 1
 UPDATE foo SET c=2 WHERE a='a' IF b=1
 applied=false (pre-condition b=1 not met)
 Cassandra already checks for incompatible preconditions within a batch (eg 
 one statement with IF c=1 and another statement with IF c=2). It should also 
 check for mutations to columns in one statement that affect the 
 pre-conditions of another statement, or it should evaluate the statement 
 pre-conditions sequentially after applying the mutations of the previous 
 statement to an in-memory model of the partition.
 For backwards compatibility this would have to be a new strict batch mode, 
 eg.
 BEGIN STRICT BATCH



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10046) RangeTombstone validation missing on thrift

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-10046:
-
Reviewer: Sylvain Lebresne  (was: Aleksey Yeschenko)

 RangeTombstone validation missing on thrift
 ---

 Key: CASSANDRA-10046
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10046
 Project: Cassandra
  Issue Type: Bug
Reporter: T Jake Luciani
Assignee: T Jake Luciani
Priority: Minor
 Fix For: 3.0.0 rc1


 Currently a number of thrift tests fail due to a NPE
 {code}
 test_range_deletion 
 test_batch_mutate_remove_slice_standard
 test_batch_mutate_remove_slice_of_entire_supercolumns
 {code}
 These errors all stem from the fact we aren't properly throwing a validation 
 exception when a deletion with a slice that is not start == finish.  
 We should add better validation to throw a clear exception sooner.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-9966) Option to apply statements within a batch sequentially

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-9966:

Summary: Option to apply statements within a batch sequentially  (was: 
batched CAS statements are not serializable)

 Option to apply statements within a batch sequentially
 --

 Key: CASSANDRA-9966
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9966
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Sam Overton
Assignee: Sylvain Lebresne
 Fix For: 3.x, 2.2.x


 It is possible to batch CAS statements such that their outcome is different 
 to the outcome were they executed sequentially outside of a batch.
 eg.
 a | b | c
 a | 1 | 1
 BEGIN BATCH
 UPDATE foo SET b=2 WHERE a='a' iF c=1
 UPDATE foo SET c=2 WHERE a='a' IF b=1
 APPLY BATCH
 results in 
 a | b | c
 a | 2 | 2
 If these statements were not batched, the outcome would be 
 UPDATE foo SET b=2 WHERE a='a' iF c=1
 a | b | c
 a | 2 | 1
 UPDATE foo SET c=2 WHERE a='a' IF b=1
 applied=false (pre-condition b=1 not met)
 Cassandra already checks for incompatible preconditions within a batch (eg 
 one statement with IF c=1 and another statement with IF c=2). It should also 
 check for mutations to columns in one statement that affect the 
 pre-conditions of another statement, or it should evaluate the statement 
 pre-conditions sequentially after applying the mutations of the previous 
 statement to an in-memory model of the partition.
 For backwards compatibility this would have to be a new strict batch mode, 
 eg.
 BEGIN STRICT BATCH



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CASSANDRA-8903) Super Columns exception during upgrade from C* 1.2.18 to C* 2.0.11

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne resolved CASSANDRA-8903.
-
Resolution: Cannot Reproduce

As said above, it's very unclear from the code of such exception could happen 
and with no news on reproduction steps in 1+ month (and no additional report of 
this), closing as Cannot Reproduce.

If you have more information to provide on this that would help 
reproducing/tracking this down, feel free to reopen with said information. 

 Super Columns exception during upgrade from C* 1.2.18 to C* 2.0.11
 --

 Key: CASSANDRA-8903
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8903
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Erick Ramirez
Assignee: Sylvain Lebresne

 While in the middle of an upgrade of a 12-node cluster, the following errors 
 were constantly being reported in the logs:
 {noformat}
 ERROR [WRITE-/10.73.73.26] 2015-03-02 22:59:12,523 OutboundTcpConnection.java 
 (line 234) error writing to /xx.xx.xx.xx 
 java.lang.RuntimeException: Cannot convert filter to old super column format. 
 Update all nodes to Cassandra 2.0 first. 
 at 
 org.apache.cassandra.db.SuperColumns.sliceFilterToSC(SuperColumns.java:353) 
 at org.apache.cassandra.db.SuperColumns.filterToSC(SuperColumns.java:258) 
 at 
 org.apache.cassandra.db.RangeSliceCommandSerializer.serializedSize(RangeSliceCommand.java:284)
  
 at 
 org.apache.cassandra.db.RangeSliceCommandSerializer.serializedSize(RangeSliceCommand.java:156)
  
 at org.apache.cassandra.net.MessageOut.serialize(MessageOut.java:116) 
 at 
 org.apache.cassandra.net.OutboundTcpConnection.writeInternal(OutboundTcpConnection.java:251)
  
 at 
 org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:203)
  
 at 
 org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:151)
 {noformat}
 Confirmed that code is accessing cluster via Thrift and not CQL API.
 This issue is very similar to CASSANDRA-6966 but may relate to the way that 
 single slice and reversed is being handled.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10073) Counter mutation serialization bug

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10073:
--

Pushed branch with the fixes 
[here|https://github.com/pcmanus/cassandra/commits/10073] (I'll update with 
links to CI results once/if the branch is picked up by cassci).

The reason for the exception is that {{CollectionType.validateCellValue}} is 
not calling the proper validation method for it's values (it should call their 
{{validateCellValue}}). This is not a particularly new bug, but the only types 
for which {{validate}} and {{validateCellValue}} differs are collections (but 
we don't support nested collections) and counters (for which, prior to 
CASSANDRA-8099 were never part of collections -- they can be now if counters 
are used in thrift super columns). The first commit fixes that.

Once that was fixed, the test was still failing due to some pretty clear typo 
in {{ColumnSubselection}} serialization code, so a 2nd commit fixes that too.

 Counter mutation serialization bug
 --

 Key: CASSANDRA-10073
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10073
 Project: Cassandra
  Issue Type: Bug
Reporter: T Jake Luciani
Assignee: Sylvain Lebresne
Priority: Critical
 Fix For: 3.0 beta 1


 reproduced in dtest 
 super_counter_test:TestSuperCounterClusterRestart.functional_test_2
 {code}
 - Unexpected error deserializing mutation; saved to 
 /tmp/mutation181379301016027337dat and ignored.  This may be caused by 
 replaying a mutation against a table with the same name but incompatible 
 schema.  Exception follows:  
 org.apache.cassandra.serializers.MarshalException: Expected 8 or 0 byte long 
 (36) \tat 
 org.apache.cassandra.serializers.LongSerializer.validate(LongSerializer.java:42)
  ~[main/:na] \tat 
 org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:122) 
 ~[main/:na] \tat 
 org.apache.cassandra.db.marshal.CollectionType.validateCellValue(CollectionType.java:130)
  ~[main/:na] \tat 
 org.apache.cassandra.config.ColumnDefinition.validateCellValue(ColumnDefinition.java:444)
  ~[main/:na] \tat 
 org.apache.cassandra.db.rows.AbstractCell.validate(AbstractCell.java:56) 
 ~[main/:na] \tat 
 org.apache.cassandra.db.rows.ComplexColumnData.validate(ComplexColumnData.java:125)
  ~[main/:na] \tat 
 org.apache.cassandra.db.partitions.PartitionUpdate.validate(PartitionUpdate.java:518)
  ~[main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.replayMutation(CommitLogReplayer.java:485)
  [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.replaySyncSection(CommitLogReplayer.java:465)
  [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:371)
  [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:146)
  [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:181) 
 [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:161) 
 [main/:na] \tat 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:272) 
 [main/:na] \tat 
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:512)
  [main/:na] \tat 
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:618) 
 [main/:na] ERROR [main] 2015-08-12 17:36:38,247 CommitLogReplayer.java:513
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10073) Counter mutation serialization bug

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-10073:
-
   Reviewer: Aleksey Yeschenko
Description: 


reproduced in dtest 
super_counter_test:TestSuperCounterClusterRestart.functional_test_2

{code}
- Unexpected error deserializing mutation; saved to 
/tmp/mutation181379301016027337dat and ignored.  This may be caused by 
replaying a mutation against a table with the same name but incompatible 
schema.  Exception follows:  org.apache.cassandra.serializers.MarshalException: 
Expected 8 or 0 byte long (36) \tat 
org.apache.cassandra.serializers.LongSerializer.validate(LongSerializer.java:42)
 ~[main/:na] \tat 
org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:122) 
~[main/:na] \tat 
org.apache.cassandra.db.marshal.CollectionType.validateCellValue(CollectionType.java:130)
 ~[main/:na] \tat 
org.apache.cassandra.config.ColumnDefinition.validateCellValue(ColumnDefinition.java:444)
 ~[main/:na] \tat 
org.apache.cassandra.db.rows.AbstractCell.validate(AbstractCell.java:56) 
~[main/:na] \tat 
org.apache.cassandra.db.rows.ComplexColumnData.validate(ComplexColumnData.java:125)
 ~[main/:na] \tat 
org.apache.cassandra.db.partitions.PartitionUpdate.validate(PartitionUpdate.java:518)
 ~[main/:na] \tat 
org.apache.cassandra.db.commitlog.CommitLogReplayer.replayMutation(CommitLogReplayer.java:485)
 [main/:na] \tat 
org.apache.cassandra.db.commitlog.CommitLogReplayer.replaySyncSection(CommitLogReplayer.java:465)
 [main/:na] \tat 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:371)
 [main/:na] \tat 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:146)
 [main/:na] \tat 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:181) 
[main/:na] \tat 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:161) 
[main/:na] \tat 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:272) 
[main/:na] \tat 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:512) 
[main/:na] \tat 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:618) 
[main/:na] ERROR [main] 2015-08-12 17:36:38,247 CommitLogReplayer.java:513
{code}

  was:



reproduced in dtest 
super_counter_test:TestSuperCounterClusterRestart.functional_test_2

{code}
- Unexpected error deserializing mutation; saved to 
/tmp/mutation181379301016027337dat and ignored.  This may be caused by 
replaying a mutation against a table with the same name but incompatible 
schema.  Exception follows:  org.apache.cassandra.serializers.MarshalException: 
Expected 8 or 0 byte long (36) \tat 
org.apache.cassandra.serializers.LongSerializer.validate(LongSerializer.java:42)
 ~[main/:na] \tat 
org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:122) 
~[main/:na] \tat 
org.apache.cassandra.db.marshal.CollectionType.validateCellValue(CollectionType.java:130)
 ~[main/:na] \tat 
org.apache.cassandra.config.ColumnDefinition.validateCellValue(ColumnDefinition.java:444)
 ~[main/:na] \tat 
org.apache.cassandra.db.rows.AbstractCell.validate(AbstractCell.java:56) 
~[main/:na] \tat 
org.apache.cassandra.db.rows.ComplexColumnData.validate(ComplexColumnData.java:125)
 ~[main/:na] \tat 
org.apache.cassandra.db.partitions.PartitionUpdate.validate(PartitionUpdate.java:518)
 ~[main/:na] \tat 
org.apache.cassandra.db.commitlog.CommitLogReplayer.replayMutation(CommitLogReplayer.java:485)
 [main/:na] \tat 
org.apache.cassandra.db.commitlog.CommitLogReplayer.replaySyncSection(CommitLogReplayer.java:465)
 [main/:na] \tat 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:371)
 [main/:na] \tat 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:146)
 [main/:na] \tat 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:181) 
[main/:na] \tat 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:161) 
[main/:na] \tat 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:272) 
[main/:na] \tat 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:512) 
[main/:na] \tat 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:618) 
[main/:na] ERROR [main] 2015-08-12 17:36:38,247 CommitLogReplayer.java:513
{code}


 Counter mutation serialization bug
 --

 Key: CASSANDRA-10073
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10073
 Project: Cassandra
  Issue Type: Bug
Reporter: T Jake Luciani
Assignee: Sylvain Lebresne
Priority: Critical
 Fix For: 3.0 beta 1


 reproduced in dtest 
 super_counter_test:TestSuperCounterClusterRestart.functional_test_2
 {code}
 - Unexpected error 

[jira] [Assigned] (CASSANDRA-10073) Counter mutation serialization bug

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne reassigned CASSANDRA-10073:


Assignee: Sylvain Lebresne  (was: Aleksey Yeschenko)

 Counter mutation serialization bug
 --

 Key: CASSANDRA-10073
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10073
 Project: Cassandra
  Issue Type: Bug
Reporter: T Jake Luciani
Assignee: Sylvain Lebresne
Priority: Critical
 Fix For: 3.0 beta 1


 reproduced in dtest 
 super_counter_test:TestSuperCounterClusterRestart.functional_test_2
 {code}
 - Unexpected error deserializing mutation; saved to 
 /tmp/mutation181379301016027337dat and ignored.  This may be caused by 
 replaying a mutation against a table with the same name but incompatible 
 schema.  Exception follows:  
 org.apache.cassandra.serializers.MarshalException: Expected 8 or 0 byte long 
 (36) \tat 
 org.apache.cassandra.serializers.LongSerializer.validate(LongSerializer.java:42)
  ~[main/:na] \tat 
 org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:122) 
 ~[main/:na] \tat 
 org.apache.cassandra.db.marshal.CollectionType.validateCellValue(CollectionType.java:130)
  ~[main/:na] \tat 
 org.apache.cassandra.config.ColumnDefinition.validateCellValue(ColumnDefinition.java:444)
  ~[main/:na] \tat 
 org.apache.cassandra.db.rows.AbstractCell.validate(AbstractCell.java:56) 
 ~[main/:na] \tat 
 org.apache.cassandra.db.rows.ComplexColumnData.validate(ComplexColumnData.java:125)
  ~[main/:na] \tat 
 org.apache.cassandra.db.partitions.PartitionUpdate.validate(PartitionUpdate.java:518)
  ~[main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.replayMutation(CommitLogReplayer.java:485)
  [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.replaySyncSection(CommitLogReplayer.java:465)
  [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:371)
  [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:146)
  [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:181) 
 [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:161) 
 [main/:na] \tat 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:272) 
 [main/:na] \tat 
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:512)
  [main/:na] \tat 
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:618) 
 [main/:na] ERROR [main] 2015-08-12 17:36:38,247 CommitLogReplayer.java:513
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10086) Add a CLEAR cqlsh command to clear the console

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10086:
--

Thanks for the patch Paul, it's definitely +1. 

Only one trivial nit: {{clearCommand}} should perhaps follow existing 
commands. I know we managed to break the order already, but existing commands 
are mostly ordered so we may want to move clearCommand after exitCommand, or it 
can be done during commit.

I tested it manually on Linux and it works. I could not test it on Windows or 
Mac.

As for automated tests, have a look at _cqlsh_tests/cqlsh_tests.py_ in the 
[distributed tests|https://github.com/riptano/cassandra-dtest]. Normally we 
check a cqlsh command by looking at its output. In this case it is a bit tricky 
though as there is no output and the lack of output doesn't necessarily mean 
the screen was cleared. Still, we could perhaps just add a test to show that 
there is no error, to at least exercise the new code path.

If it is too time consuming to install the distributed tests I can write a test 
for you as it won't take me long.

[~jbellis]: this is only for trunk or previous versions too?

 Add a CLEAR cqlsh command to clear the console
 

 Key: CASSANDRA-10086
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10086
 Project: Cassandra
  Issue Type: Improvement
Reporter: Paul O'Fallon
Priority: Trivial
  Labels: cqlsh
 Attachments: 10086.txt


 It would be very helpful to have a CLEAR command to clear the cqlsh 
 console.  I learned (after researching a patch for this) that lowercase 
 CTRL+L will clear the screen, but having a discrete command would make that 
 more obvious.  To match the expectations of Windows users, an alias to CLS 
 would be nice as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9460) NullPointerException Creating Digest

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-9460:
-

I think this is still happening in 2.1:

http://cassci.datastax.com/job/cassandra-2.1_dtest/223/testReport/consistency_test/TestConsistency/short_read_reversed_test/

{code}
Unexpected error in node1 node log: ['ERROR [ReadRepairStage:2] 2015-08-14 
16:23:58,917 CassandraDaemon.java:223 - Exception in thread 
Thread[ReadRepairStage:2,5,main] java.lang.NullPointerException: null \tat 
org.apache.cassandra.db.ColumnFamily.updateDigest(ColumnFamily.java:390) 
~[main/:na] \tat 
org.apache.cassandra.db.ColumnFamily.digest(ColumnFamily.java:383) ~[main/:na] 
\tat 
org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:90)
 ~[main/:na] \tat 
org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:28)
 ~[main/:na] \tat 
org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:191)
 ~[main/:na] \tat 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
~[na:1.7.0_80] \tat 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
~[na:1.7.0_80] \tat java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]']
{code}

 NullPointerException Creating Digest
 

 Key: CASSANDRA-9460
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9460
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Tyler Hobbs
Assignee: Stefania
 Fix For: 2.1.9, 2.2.0

 Attachments: node2.log


 In the {{consistency_test.TestConsistency.short_read_test}} dtest against 
 cassandra-2.1, the following error occured:
 {noformat}
 ERROR [ReadRepairStage:3] 2015-05-22 16:35:25,034 CassandraDaemon.java:223 - 
 Exception in thread Thread[ReadRepairStage:3,5,main]
 java.lang.NullPointerException: null
 at 
 org.apache.cassandra.db.ColumnFamily.updateDigest(ColumnFamily.java:390) 
 ~[main/:na]
 at org.apache.cassandra.db.ColumnFamily.digest(ColumnFamily.java:383) 
 ~[main/:na]
 at 
 org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:84)
  ~[main/:na]
 at 
 org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:28)
  ~[main/:na]
 at 
 org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:176)
  ~[main/:na]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  ~[na:1.7.0_80]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  ~[na:1.7.0_80]
 at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]
 {noformat}
 From a glance at the code in the stacktrace, it looks like there was a null 
 cell in the ColumnFamily that we were creating a digest of.  This error is 
 probably particular to short reads.
 Here's the failing test: 
 http://cassci.datastax.com/job/cassandra-2.1_dtest/lastCompletedBuild/testReport/consistency_test/TestConsistency/short_read_test/.
   I've attached the logs for the node with the error.
 We saw this issue against 2.1, but the problem may also exist with 2.0 and/or 
 2.2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (CASSANDRA-9460) NullPointerException Creating Digest

[Stefania (JIRA)]

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

Stefania reopened CASSANDRA-9460:
-

 NullPointerException Creating Digest
 

 Key: CASSANDRA-9460
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9460
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Tyler Hobbs
Assignee: Stefania
 Fix For: 2.1.9, 2.2.0

 Attachments: node2.log


 In the {{consistency_test.TestConsistency.short_read_test}} dtest against 
 cassandra-2.1, the following error occured:
 {noformat}
 ERROR [ReadRepairStage:3] 2015-05-22 16:35:25,034 CassandraDaemon.java:223 - 
 Exception in thread Thread[ReadRepairStage:3,5,main]
 java.lang.NullPointerException: null
 at 
 org.apache.cassandra.db.ColumnFamily.updateDigest(ColumnFamily.java:390) 
 ~[main/:na]
 at org.apache.cassandra.db.ColumnFamily.digest(ColumnFamily.java:383) 
 ~[main/:na]
 at 
 org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:84)
  ~[main/:na]
 at 
 org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:28)
  ~[main/:na]
 at 
 org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:176)
  ~[main/:na]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  ~[na:1.7.0_80]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  ~[na:1.7.0_80]
 at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]
 {noformat}
 From a glance at the code in the stacktrace, it looks like there was a null 
 cell in the ColumnFamily that we were creating a digest of.  This error is 
 probably particular to short reads.
 Here's the failing test: 
 http://cassci.datastax.com/job/cassandra-2.1_dtest/lastCompletedBuild/testReport/consistency_test/TestConsistency/short_read_test/.
   I've attached the logs for the node with the error.
 We saw this issue against 2.1, but the problem may also exist with 2.0 and/or 
 2.2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-10089) NullPointerException in Gossip handleStateNormal

[Stefania (JIRA)]

Stefania created CASSANDRA-10089:


 Summary: NullPointerException in Gossip handleStateNormal
 Key: CASSANDRA-10089
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10089
 Project: Cassandra
  Issue Type: Bug
Reporter: Stefania
Assignee: Stefania


Whilst comparing dtests for CASSANDRA-9970 I found [this failing 
dtest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-9970-dtest/lastCompletedBuild/testReport/consistency_test/TestConsistency/short_read_test/]
 in 2.2:

{code}
Unexpected error in node1 node log: ['ERROR [GossipStage:1] 2015-08-14 
15:39:57,873 CassandraDaemon.java:183 - Exception in thread 
Thread[GossipStage:1,5,main] java.lang.NullPointerException: null \tat 
org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1731)
 ~[main/:na] \tat 
org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1804)
 ~[main/:na] \tat 
org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1857)
 ~[main/:na] \tat 
org.apache.cassandra.service.StorageService.onChange(StorageService.java:1629) 
~[main/:na] \tat 
org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2312) 
~[main/:na] \tat 
org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1025) 
~[main/:na] \tat 
org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1106) 
~[main/:na] \tat 
org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
 ~[main/:na] \tat 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66) 
~[main/:na] \tat 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
~[na:1.7.0_80] \tat 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
~[na:1.7.0_80] \tat java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]']
{code}

I wasn't able to find it on unpatched branches  but it is clearly not related 
to CASSANDRA-9970, if anything it could have been a side effect of 
CASSANDRA-9871.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CASSANDRA-10088) sequential batch operation

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis resolved CASSANDRA-10088.

Resolution: Invalid

Please take QA to Stack Overflow or the mailing list.

 sequential batch operation
 --

 Key: CASSANDRA-10088
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10088
 Project: Cassandra
  Issue Type: Test
  Components: Config, Core
Reporter: Rohit Kasat

 Is it possible to do sequential batch.
 eg:
  batch delete from table 1, and same time take some id's from table 2
  pass this to delete operion and delete from table 2.
 and so on. 
 if any deletion fails fail everything.
 (Its kind of transactional)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-10088) sequential batch operation

[Rohit Kasat (JIRA)]

Rohit Kasat created CASSANDRA-10088:
---

 Summary: sequential batch operation
 Key: CASSANDRA-10088
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10088
 Project: Cassandra
  Issue Type: Test
  Components: Config, Core
Reporter: Rohit Kasat


Is it possible to do sequential batch.
eg:
 batch delete from table 1, and same time take some id's from table 2
 pass this to delete operion and delete from table 2.
and so on. 
if any deletion fails fail everything.

(Its kind of transactional)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9906) get_slice and multiget_slice failing on trunk

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-9906:
-

The utests are definitely OK and the dtests seem inline with 3.0 so I am +1.

 get_slice and multiget_slice failing on trunk
 -

 Key: CASSANDRA-9906
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9906
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Mike Adamson
Assignee: Benjamin Lerer
Priority: Blocker
 Fix For: 3.0.0 rc1

 Attachments: 9906.txt, dtest-CASSANDRA-9906.txt


 {{get_slice}} and {{multiget_slice}} are failing on trunk with the following 
 error:
 {noformat}
 java.lang.AssertionError: null
   at 
 org.apache.cassandra.db.filter.ClusteringIndexNamesFilter.init(ClusteringIndexNamesFilter.java:53)
  ~[cassandra-all-3.0.0.592.jar:3.0.0.592]
   at 
 org.apache.cassandra.thrift.CassandraServer.toInternalFilter(CassandraServer.java:405)
  ~[cassandra-all-3.0.0.592.jar:5.0.0-SNAPSHOT]
   at 
 org.apache.cassandra.thrift.CassandraServer.multigetSliceInternal(CassandraServer.java:547)
  ~[cassandra-all-3.0.0.592.jar:5.0.0-SNAPSHOT]
   at 
 org.apache.cassandra.thrift.CassandraServer.multiget_slice(CassandraServer.java:348)
  ~[cassandra-all-3.0.0.592.jar:5.0.0-SNAPSHOT]
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$multiget_slice.getResult(Cassandra.java:3716)
  ~[cassandra-thrift-3.0.0.592.jar:5.0.0-SNAPSHOT]
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$multiget_slice.getResult(Cassandra.java:3700)
  ~[cassandra-thrift-3.0.0.592.jar:5.0.0-SNAPSHOT]
   at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39) 
 ~[libthrift-0.9.2.jar:0.9.2]
   at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) 
 ~[libthrift-0.9.2.jar:0.9.2]
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:204)
  ~[cassandra-all-3.0.0.592.jar:5.0.0-SNAPSHOT]
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
  ~[na:1.8.0_45]
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  ~[na:1.8.0_45]
   at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
 {noformat}
 The schema used for this was
 {noformat}
 create table test (k int, v int, primary key(k)) with compact storage;
 {noformat}
 and the code used for the call was
 {noformat}
 SlicePredicate predicate = new SlicePredicate();
 predicate.column_names = 
 Collections.singletonList(ByteBufferUtil.bytes(v));
 client.multiget_slice(Collections.singletonList(key), new 
 ColumnParent(test), predicate, ConsistencyLevel.ONE);
 {noformat}
 The error is coming from this line in {{ClusteringIndexNamesFilter}}
 {noformat}
 assert !clusterings.contains(Clustering.STATIC_CLUSTERING);
 {noformat}
 which is failing the assertion because column 'v' is static.
 Apologies for the line mismatches in {{ClusteringIndexNamesFilter}} I had 
 some debug statements in the code to help track down what was happening



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9970) CQL 3.3 ordering in where clause produces different results when using IN...ORDER BY

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-9970:
-

+1.

I found a dtest on 2.2 happening only on this branch but it is clearly 
unrelated (Gossip) and therefore I opened CASSANDRA-10089 for it.

 CQL 3.3 ordering in where clause produces different results when using 
 IN...ORDER BY
 --

 Key: CASSANDRA-9970
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9970
 Project: Cassandra
  Issue Type: Bug
  Components: API
Reporter: Marc Zbyszynski
Assignee: Benjamin Lerer
Priority: Minor
 Fix For: 2.2.x

 Attachments: 9970.txt, dtest-CASSANDRA-9970.txt


 This is an issue I found with
 {code}
 [cqlsh 5.0.1 | Cassandra 2.2.0 | CQL spec 3.3.0 | Native protocol v4]
 {code}
 Given this table and data:
 {code:sql}
 cqlsh CREATE TABLE myschema.in_test (
... col_1 int,
... col_2 int,
... col_3 int,
... PRIMARY KEY ((col_1, col_2), col_3)
... );
 cqlsh INSERT INTO myschema.in_test (col_1, col_2, col_3) VALUES(1, 1, 1);
 cqlsh INSERT INTO myschema.in_test (col_1, col_2, col_3) VALUES(1, 1, 2);
 cqlsh INSERT INTO myschema.in_test (col_1, col_2, col_3) VALUES(1, 1, 13);
 cqlsh INSERT INTO myschema.in_test (col_1, col_2, col_3) VALUES(1, 2, 10);
 cqlsh INSERT INTO myschema.in_test (col_1, col_2, col_3) VALUES(1, 2, 11);
 {code}
 This query behaves as expected (as described in 
 [http://docs.datastax.com/en/cql/3.3/cql/cql_using/useQueryIN.html])
 {code:sql}
 cqlsh select * from myschema.in_test where col_1=1 and col_2 IN (1,2) order 
 by col_3 desc;
 InvalidRequest: code=2200 [Invalid query] message=Cannot page queries with 
 both ORDER BY and a IN restriction on the partition key; you must either 
 remove the ORDER BY or the IN and sort client side, or disable paging for 
 this query
 {code}
 But if you swap the order of the statements in the where clause, the query 
 executes without error and doesn't totally honor the _order by_ clause:
 {code:sql}
 cqlsh select * from myschema.in_test where col_2 IN (1,2) and col_1=1 order 
 by col_3 desc;
  col_1 | col_2 | col_3
 ---+---+---
  1 | 2 |11
  1 | 2 |10
  1 | 1 |13
  1 | 1 | 2
  1 | 1 | 1
 (5 rows)
 {code}
 Apologies in advance if this is working as intended, or I'm duplicating an 
 existing issue. Also please let me know if you need any additional info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10073) Counter mutation serialization bug

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10073:
--

CI results: [utests|http://cassci.datastax.com/job/pcmanus-10073-testall/1/] 
and [dtests|http://cassci.datastax.com/job/pcmanus-10073-dtest/1/].

Compared to the last results on the cassandra-3.0 branch:
* for the unit tests, there is a failure of 
{{org.apache.cassandra.cql3.MaterializedViewLongTest.testConflictResolution}} 
but I can't really imagine how the patch here could in any way influence that 
test so I strongly suspect a flaky test.
* for the dtests, it fixes the test of the description as expected (in fact, 
the run has only 27 failures compared to 33 on the last cassandra-3.0 run, but 
the rest is probably flaky tests for which the run got lucky).


 Counter mutation serialization bug
 --

 Key: CASSANDRA-10073
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10073
 Project: Cassandra
  Issue Type: Bug
Reporter: T Jake Luciani
Assignee: Sylvain Lebresne
Priority: Critical
 Fix For: 3.0 beta 1


 reproduced in dtest 
 super_counter_test:TestSuperCounterClusterRestart.functional_test_2
 {code}
 - Unexpected error deserializing mutation; saved to 
 /tmp/mutation181379301016027337dat and ignored.  This may be caused by 
 replaying a mutation against a table with the same name but incompatible 
 schema.  Exception follows:  
 org.apache.cassandra.serializers.MarshalException: Expected 8 or 0 byte long 
 (36) \tat 
 org.apache.cassandra.serializers.LongSerializer.validate(LongSerializer.java:42)
  ~[main/:na] \tat 
 org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:122) 
 ~[main/:na] \tat 
 org.apache.cassandra.db.marshal.CollectionType.validateCellValue(CollectionType.java:130)
  ~[main/:na] \tat 
 org.apache.cassandra.config.ColumnDefinition.validateCellValue(ColumnDefinition.java:444)
  ~[main/:na] \tat 
 org.apache.cassandra.db.rows.AbstractCell.validate(AbstractCell.java:56) 
 ~[main/:na] \tat 
 org.apache.cassandra.db.rows.ComplexColumnData.validate(ComplexColumnData.java:125)
  ~[main/:na] \tat 
 org.apache.cassandra.db.partitions.PartitionUpdate.validate(PartitionUpdate.java:518)
  ~[main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.replayMutation(CommitLogReplayer.java:485)
  [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.replaySyncSection(CommitLogReplayer.java:465)
  [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:371)
  [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:146)
  [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:181) 
 [main/:na] \tat 
 org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:161) 
 [main/:na] \tat 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:272) 
 [main/:na] \tat 
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:512)
  [main/:na] \tat 
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:618) 
 [main/:na] ERROR [main] 2015-08-12 17:36:38,247 CommitLogReplayer.java:513
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CASSANDRA-10046) RangeTombstone validation missing on thrift

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne reassigned CASSANDRA-10046:


Assignee: Sylvain Lebresne  (was: T Jake Luciani)

 RangeTombstone validation missing on thrift
 ---

 Key: CASSANDRA-10046
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10046
 Project: Cassandra
  Issue Type: Bug
Reporter: T Jake Luciani
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 3.0.0 rc1


 Currently a number of thrift tests fail due to a NPE
 {code}
 test_range_deletion 
 test_batch_mutate_remove_slice_standard
 test_batch_mutate_remove_slice_of_entire_supercolumns
 {code}
 These errors all stem from the fact we aren't properly throwing a validation 
 exception when a deletion with a slice that is not start == finish.  
 We should add better validation to throw a clear exception sooner.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10046) RangeTombstone validation missing on thrift

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10046:
--

For the record, this is a regression from CASSANDRA-9704.

This is also not a validation issue, as those test should be passing and we do 
want to handle range tombstones whose start differ from their end.

As far as I can tell, the problem is in the 
{{LegacyLayout.LegacyDeletionInfo.from}} method: it basically ends up 
considering all RT as a in-row tombstone, which is definitively incorrect. And 
in fact, that methods takes a {{DeletionInfo}}, so it can't have any in-row 
tombstone by definition. So I think the simplest way to deal with this is to 
have {{CassandraServer}} adds to a {{LegacyDeletionInfo}} object directly 
(instead of a {{DeletionInfo}}) and have it deal with in-row tombstones 
directly. Pushed a branch to do so 
[here|https://github.com/pcmanus/cassandra/commits/10046].

CI results will be eventually avaible for the 
[utests|http://cassci.datastax.com/view/Dev/view/pcmanus/job/pcmanus-10046-testall/]
 and 
[dtests|http://cassci.datastax.com/view/Dev/view/pcmanus/job/pcmanus-10046-dtest/].

Marking [~thobbs] as reviewer since he is the original author of CASSANDRA-9704.


 RangeTombstone validation missing on thrift
 ---

 Key: CASSANDRA-10046
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10046
 Project: Cassandra
  Issue Type: Bug
Reporter: T Jake Luciani
Assignee: T Jake Luciani
Priority: Minor
 Fix For: 3.0.0 rc1


 Currently a number of thrift tests fail due to a NPE
 {code}
 test_range_deletion 
 test_batch_mutate_remove_slice_standard
 test_batch_mutate_remove_slice_of_entire_supercolumns
 {code}
 These errors all stem from the fact we aren't properly throwing a validation 
 exception when a deletion with a slice that is not start == finish.  
 We should add better validation to throw a clear exception sooner.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-9130) reduct default dtcs max_sstable_age

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-9130:
---
Assignee: Jeff Jirsa  (was: Marcus Eriksson)

 reduct default dtcs max_sstable_age
 ---

 Key: CASSANDRA-9130
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9130
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jonathan Ellis
Assignee: Jeff Jirsa
Priority: Minor
 Fix For: 3.x, 2.1.x, 2.0.x


 Now that CASSANDRA-9056 is fixed it should be safe to reduce the default age 
 and increase performance correspondingly.  [~jshook] suggests that two weeks 
 may be appropriate, or we could make it dynamic based on gcgs (since that's 
 the window past which we should expect repair to not introduce fragmentation 
 anymore).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10060) Reuse TemporalRow when updating multiple MaterializedViews

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-10060:


Overall, +1. {{TemporalRow.Type}} isn't really necessary - we always call 
{{setTombstonedExisting}} after we do the tombstone, so the extra state doesn't 
add more information, we could go back to the {{isNew}} flag instead.

 Reuse TemporalRow when updating multiple MaterializedViews
 --

 Key: CASSANDRA-10060
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10060
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Assignee: T Jake Luciani
 Fix For: 3.0.0 rc1


 If a table has 5 associated MVs the current logic reads the existing row for 
 the incoming mutation 5 times. 
 If we reuse the data from the first MV update we can cut out any further 
 reads.
 We know the existing data isn't changing because we are holding a lock on the 
 partition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10061) Only use batchlog when paired view replica is remote

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-10061:


+1

 Only use batchlog when paired view replica is remote
 

 Key: CASSANDRA-10061
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10061
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Assignee: T Jake Luciani
 Fix For: 3.0.0 rc1


 As described in the MV design doc the base and view replicas are paired one 
 to one.
 If the replica selected for the view is the local node itself there is no 
 need to create a local batchlog and we can simply apply the view mutations 
 locally.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10046) RangeTombstone validation missing on thrift

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-10046:
-
Reviewer: Tyler Hobbs  (was: Sylvain Lebresne)

 RangeTombstone validation missing on thrift
 ---

 Key: CASSANDRA-10046
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10046
 Project: Cassandra
  Issue Type: Bug
Reporter: T Jake Luciani
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 3.0.0 rc1


 Currently a number of thrift tests fail due to a NPE
 {code}
 test_range_deletion 
 test_batch_mutate_remove_slice_standard
 test_batch_mutate_remove_slice_of_entire_supercolumns
 {code}
 These errors all stem from the fact we aren't properly throwing a validation 
 exception when a deletion with a slice that is not start == finish.  
 We should add better validation to throw a clear exception sooner.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)