date:20130723

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

Jonathan Ellis commented on CASSANDRA-5793:
---

bq. One possibility is that getToken of OPP can return hex value if it fails to
encode bytes to UTF-8 instead of throwing error.

I can't think of how it would break anything to accept keys we previously
rejected.

OPP seems completely unsupported

git commit: Update versions for 1.2.7 release

Updated Branches:
  refs/heads/cassandra-1.2 0f0a11c97 - ae62c947f


Update versions for 1.2.7 release


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

Branch: refs/heads/cassandra-1.2
Commit: ae62c947fc245295785324502bf6bc2c1c8477f9
Parents: 0f0a11c
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Jul 23 15:44:09 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Jul 23 15:44:09 2013 +0200

--
 NEWS.txt | 1 +
 build.xml| 2 +-
 debian/changelog | 6 ++
 3 files changed, 8 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae62c947/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index d4d127b..9a7dd51 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -15,6 +15,7 @@ using the provided 'sstableupgrade' tool.
 
 1.2.7
 =
+
 Upgrading
 -
 - If you have decommissioned a node in the past 72 hours, it is imperative

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae62c947/build.xml
--
diff --git a/build.xml b/build.xml
index 8d54554..523a225 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 property name=debuglevel value=source,lines,vars/
 
 !-- default version and SCM information --
-property name=base.version value=1.2.6/
+property name=base.version value=1.2.7/
 property name=scm.connection 
value=scm:git://git.apache.org/cassandra.git/
 property name=scm.developerConnection 
value=scm:git://git.apache.org/cassandra.git/
 property name=scm.url 
value=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree/

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae62c947/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 3be9ba0..d0c7017 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (1.2.7) unstable; urgency=low
+
+  * New release
+
+ -- Sylvain Lebresne slebre...@apache.org  Tue, 23 Jul 2013 15:42:51 +0200
+
 cassandra (1.2.6) unstable; urgency=low
 
   * New release

Git Push Summary

Updated Tags:  refs/tags/1.2.7-tentative [created] ae62c947f

[jira] [Updated] (CASSANDRA-5704) add cassandra.unsafesystem property (Truncate flushes to disk again in 1.2, even with durable_writes=false)

2013-07-23 Thread Christian Spriegel (JIRA)


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

Christian Spriegel updated CASSANDRA-5704:
--

Summary: add cassandra.unsafesystem property (Truncate flushes to disk 
again in 1.2, even with durable_writes=false)  (was: Truncate flushes to disk 
again in 1.2, even with durable_writes=false)

 add cassandra.unsafesystem property (Truncate flushes to disk again in 1.2, 
 even with durable_writes=false)
 ---

 Key: CASSANDRA-5704
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5
Reporter: Christian Spriegel
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 1.2.7, 2.0 beta 2

 Attachments: 5704_unsafeSystem.txt, 5704-v2.txt, 
 CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch


 I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my 
 JUnit tests slow again, due to a blocking-flush in saveTruncationRecord().
 With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
 My proposal is to make saveTruncationRecord() only flush when durableWrites 
 are enabled.
 My assumption is that if somebody turn off durable writes then he does not 
 mind if truncate is not guaranteed to be durable either.
 I successfully tested the following patch with my testsuite. Its as fast as 
 it was with 1.1 (maybe even faster!):
 {code}
 @@ -186,5 +186,8 @@ public class SystemTable
  String req = UPDATE system.%s SET truncated_at = truncated_at + %s 
 WHERE key = '%s';
  processInternal(String.format(req, LOCAL_CF, 
 truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY));
 -forceBlockingFlush(LOCAL_CF);
 +
 +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name);
 +if (ksm.durableWrites) // flush only when durable_writes are enabled
 +forceBlockingFlush(LOCAL_CF);
  }
 {code}

--
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] [Comment Edited] (CASSANDRA-5704) add cassandra.unsafesystem property (Truncate flushes to disk again in 1.2, even with durable_writes=false)

2013-07-23 Thread Christian Spriegel (JIRA)


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

Christian Spriegel edited comment on CASSANDRA-5704 at 7/23/13 3:03 PM:


Awesome, thanks!

For documentation purposes: The property is: -Dcassandra.unsafesystem=true

  was (Author: christianmovi):
Awesome, thanks!

For documentation purposes: The property in 2.0 is: 
-Dcassandra.unsafesystem=true
  
 add cassandra.unsafesystem property (Truncate flushes to disk again in 1.2, 
 even with durable_writes=false)
 ---

 Key: CASSANDRA-5704
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5
Reporter: Christian Spriegel
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 1.2.7, 2.0 beta 2

 Attachments: 5704_unsafeSystem.txt, 5704-v2.txt, 
 CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch


 I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my 
 JUnit tests slow again, due to a blocking-flush in saveTruncationRecord().
 With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
 My proposal is to make saveTruncationRecord() only flush when durableWrites 
 are enabled.
 My assumption is that if somebody turn off durable writes then he does not 
 mind if truncate is not guaranteed to be durable either.
 I successfully tested the following patch with my testsuite. Its as fast as 
 it was with 1.1 (maybe even faster!):
 {code}
 @@ -186,5 +186,8 @@ public class SystemTable
  String req = UPDATE system.%s SET truncated_at = truncated_at + %s 
 WHERE key = '%s';
  processInternal(String.format(req, LOCAL_CF, 
 truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY));
 -forceBlockingFlush(LOCAL_CF);
 +
 +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name);
 +if (ksm.durableWrites) // flush only when durable_writes are enabled
 +forceBlockingFlush(LOCAL_CF);
  }
 {code}

--
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-5792) Buffer Underflow during streaming

2013-07-23 Thread Yuki Morishita (JIRA)


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

Yuki Morishita updated CASSANDRA-5792:
--

Attachment: 5792.txt

There is a chance we get nothing from socket,  like when socket gets closed.
Patch attached to check we actually read something from socket.

 Buffer Underflow during streaming
 -

 Key: CASSANDRA-5792
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5792
 Project: Cassandra
  Issue Type: Bug
Reporter: Brandon Williams
Assignee: Yuki Morishita
 Fix For: 2.0

 Attachments: 5792.txt


 {noformat}
 ERROR [STREAM-IN-/127.0.0.3] 2013-07-22 16:19:50,597 StreamSession.java (line 
 414) Streaming error occurred
 java.nio.BufferUnderflowException
 at java.nio.Buffer.nextGetIndex(Buffer.java:492)
 at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:135)
 at 
 org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:52)
 at 
 org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:288)
 at java.lang.Thread.run(Thread.java:722)
 {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

[jira] [Commented] (CASSANDRA-5788) StorageProxy#cas() doesn't order columns names correctly when querying

2013-07-23 Thread Edward Capriolo (JIRA)


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

Edward Capriolo commented on CASSANDRA-5788:


Can we re-open so I can put a unit test around this? I see we said this is 
trivial but I think a test could help prevent this from happening again.

 StorageProxy#cas() doesn't order columns names correctly when querying
 --

 Key: CASSANDRA-5788
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5788
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
 Fix For: 2.0 beta 2

 Attachments: 5788.txt


 When querying columns for CAS, we build the SortedSet with:
 {noformat}
 new NamesQueryFilter(ImmutableSortedSet.copyOf(expected.getColumnNames())
 {noformat}
 but ImmutableSortedSet.copyOf() uses the natural order of keys unless a 
 comparator is given, which is not what we want.

--
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-5788) StorageProxy#cas() doesn't order columns names correctly when querying


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

Jonathan Ellis commented on CASSANDRA-5788:
---

We've rolled a release w/ this now so probably best to make a new ticket, sorry.

 StorageProxy#cas() doesn't order columns names correctly when querying
 --

 Key: CASSANDRA-5788
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5788
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
 Fix For: 2.0 beta 2

 Attachments: 5788.txt


 When querying columns for CAS, we build the SortedSet with:
 {noformat}
 new NamesQueryFilter(ImmutableSortedSet.copyOf(expected.getColumnNames())
 {noformat}
 but ImmutableSortedSet.copyOf() uses the natural order of keys unless a 
 comparator is given, which is not what we want.

--
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: Add CAS to the CQL doc

Updated Branches:
  refs/heads/trunk 27056ece4 - db70bbe41


Add CAS to the CQL doc


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

Branch: refs/heads/trunk
Commit: db70bbe41438d17387e714537a4f705dae418515
Parents: 27056ec
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Jul 23 18:41:22 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Jul 23 18:41:32 2013 +0200

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/db70bbe4/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index 34a0c12..9a24ec0 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -409,7 +409,7 @@ CREATE INDEX userIndex ON NerdMovies (user);
 CREATE INDEX ON Mutants (abilityId);
 CREATE CUSTOM INDEX ON users (email) USING 'path.to.the.IndexClass';
 
-The @CREATE INDEX@ statement is used to create a new (automatic) secondary 
index for a given (existing) column in a given table. A name for the index 
itself can be specified before the @ON@ keyword, if desired. If data already 
exists for the column, it will be indexed during the execution of this 
statement. After the index is created, new data for the column is indexed 
automatically at insertion time.
+The @CREATE INDEX@ statement is used to create a new (automatic) secondary 
index for a given (existing) column in a given table. A name for the index 
itself can be specified before the @ON@ keyword, if desired. If data already 
exists for the column, it will be indexed asynchronously. After the index is 
created, new data for the column is indexed automatically at insertion time.
 
 Attempting to create an already existing index will return an error unless the 
@IF NOT EXISTS@ option is used. If it is used, the statement will be a no-op if 
the index already exists.
 
@@ -437,6 +437,7 @@ bc(syntax)..
 insertStatement ::= INSERT INTO tablename
  '(' identifier ( ',' identifier )* ')'
   VALUES '(' term-or-literal ( ',' term-or-literal )* 
')'
+  ( IF NOT EXISTS )?
   ( USING option ( AND option )* )?
 
 term-or-literal ::= term
@@ -454,7 +455,9 @@ USING TTL 86400;
 
 The @INSERT@ statement writes one or more columns for a given row in a table. 
Note that since a row is identified by its @PRIMARY KEY@, the columns that 
compose it must be specified. Also, since a row only exists when it contains 
one value for a column not part of the @PRIMARY KEY@, one such value must be 
specified too.
 
-Note that unlike in SQL, @INSERT@ does not check the prior existence of the 
row: the row is created if none existed before, and updated otherwise. 
Furthermore, there is no mean to know which of creation or update happened. In 
fact, the semantic of @INSERT@ and @UPDATE@ are identical.
+Note that unlike in SQL, @INSERT@ does not check the prior existence of the 
row by default: the row is created if none existed before, and updated 
otherwise. Furthermore, there is no mean to know which of creation or update 
happened.
+
+It is however possible to use the @IF NOT EXISTS@ condition to only insert if 
the row does not exist prior to the insertion. But please note that using @IF 
NOT EXISTS@ will incur a non negligible performance cost (internally, Paxos 
will be used) so this should be used sparingly.
 
 All updates for an @INSERT@ are applied atomically and in isolation.
 
@@ -469,6 +472,7 @@ bc(syntax)..
   ( USING option ( AND option )* )?
   SET assignment ( ',' assignment )*
   WHERE where-clause
+  ( IF identifier '=' term ( AND identifier '=' term 
)* )?
 
 assignment ::= identifier '=' term
| identifier '=' identifier ('+' | '-') (int-term | 
set-literal | list-literal)
@@ -494,7 +498,9 @@ UPDATE UserActions SET total = total + 2 WHERE user = 
B70DE1D0-9908-4AE3-BE34-55
 p. 
 The @UPDATE@ statement writes one or more columns for a given row in a table. 
The @where-clause@ is used to select the row to update and must include all 
columns composing the @PRIMARY KEY@. Other columns values are specified through 
@assignment@ after the @SET@ keyword.
 
-Note that unlike in SQL, @UPDATE@ does not check the prior existence of the 
row: the row is created if none existed before, and updated otherwise. 
Furthermore, there is no mean to know which of creation or update happened. In 
fact, the semantic of @INSERT@ and @UPDATE@ are identical.

git commit: Document multiline comments

Updated Branches:
  refs/heads/cassandra-1.2 ae62c947f - 66bd60590


Document multiline comments


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

Branch: refs/heads/cassandra-1.2
Commit: 66bd60590a82d78790c279bf1d2130b82a7d6475
Parents: ae62c94
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Jul 23 18:59:43 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Jul 23 18:59:43 2013 +0200

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/66bd6059/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index f7d2dda..44c4dd2 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -61,9 +61,13 @@ h3. Comments
 
 A comment in CQL is a line beginning by either double dashes (@--@) or double 
slash (@//@).
 
+Multi-line comments are also supported through enclosure withing @/*@ and @*/@ 
(but nesting is not supported).
+
 bc(sample). 
 -- This is a comment
 // This is a comment too
+/* This is
+   a multiline comment */
 
 h3(#statements). Statements

[1/3] git commit: Update versions for 1.2.7 release

Updated Branches:
  refs/heads/trunk db70bbe41 - 283b1a33b


Update versions for 1.2.7 release


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

Branch: refs/heads/trunk
Commit: ae62c947fc245295785324502bf6bc2c1c8477f9
Parents: 0f0a11c
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Jul 23 15:44:09 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Jul 23 15:44:09 2013 +0200

--
 NEWS.txt | 1 +
 build.xml| 2 +-
 debian/changelog | 6 ++
 3 files changed, 8 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae62c947/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index d4d127b..9a7dd51 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -15,6 +15,7 @@ using the provided 'sstableupgrade' tool.
 
 1.2.7
 =
+
 Upgrading
 -
 - If you have decommissioned a node in the past 72 hours, it is imperative

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae62c947/build.xml
--
diff --git a/build.xml b/build.xml
index 8d54554..523a225 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 property name=debuglevel value=source,lines,vars/
 
 !-- default version and SCM information --
-property name=base.version value=1.2.6/
+property name=base.version value=1.2.7/
 property name=scm.connection 
value=scm:git://git.apache.org/cassandra.git/
 property name=scm.developerConnection 
value=scm:git://git.apache.org/cassandra.git/
 property name=scm.url 
value=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree/

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae62c947/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 3be9ba0..d0c7017 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (1.2.7) unstable; urgency=low
+
+  * New release
+
+ -- Sylvain Lebresne slebre...@apache.org  Tue, 23 Jul 2013 15:42:51 +0200
+
 cassandra (1.2.6) unstable; urgency=low
 
   * New release

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

Merge branch 'cassandra-1.2' into trunk

Conflicts:
build.xml
debian/changelog


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

Branch: refs/heads/trunk
Commit: 283b1a33b47e6b9acbd30efd320ec47f8b029af4
Parents: db70bbe 66bd605
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Jul 23 19:00:36 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Jul 23 19:00:36 2013 +0200

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/283b1a33/doc/cql3/CQL.textile
--

[2/3] git commit: Document multiline comments

Document multiline comments


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

Branch: refs/heads/trunk
Commit: 66bd60590a82d78790c279bf1d2130b82a7d6475
Parents: ae62c94
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Jul 23 18:59:43 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Jul 23 18:59:43 2013 +0200

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/66bd6059/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index f7d2dda..44c4dd2 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -61,9 +61,13 @@ h3. Comments
 
 A comment in CQL is a line beginning by either double dashes (@--@) or double 
slash (@//@).
 
+Multi-line comments are also supported through enclosure withing @/*@ and @*/@ 
(but nesting is not supported).
+
 bc(sample). 
 -- This is a comment
 // This is a comment too
+/* This is
+   a multiline comment */
 
 h3(#statements). Statements

[jira] [Created] (CASSANDRA-5794) BulkOutputFormat sometimes hangs when loading small SSTables

Jim Zamata created CASSANDRA-5794:
-

 Summary: BulkOutputFormat sometimes hangs when loading small 
SSTables
 Key: CASSANDRA-5794
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5794
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Affects Versions: 1.2.6
 Environment: linux (centos 6 server, ubuntu 13.04 client)
Reporter: Jim Zamata


We have seen the bulk loader hang under some conditions.  This only seems to 
occur when the last SSTable loaded is relatively small (1144 bytes in this 
case). Turning on debug logging shows the StreamInSession starting to stream a 
file, en_oef_834_thrift-MessageData-ic-1-Data.db below, and apparently 
getting a Thrift transport error.  This loader was able to other files, some of 
them even smaller, without any problems.

The Thrift exception only appears in the debug logs, and apparently does not 
cause the stream session to fail.  It just hangs the session on both the server 
and the client until the client is killed.  When the client process is killed, 
the server then gets an unexpected EOF exception.



--
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-5794) BulkOutputFormat sometimes hangs when loading small SSTables


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

Jim Zamata commented on CASSANDRA-5794:
---

Client logs:

Client logs:
2013-07-23 16:25:12,775 INFO org.apache.cassandra.io.sstable.SSTableReader: 
Opening 
/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1
 (8 bytes)
2013-07-23 16:25:12,800 INFO org.apache.cassandra.streaming.StreamOut: Stream 
context metadata 
[/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1-Data.db
 sections=1 progress=0/8 - 0%], 1 sstables.
2013-07-23 16:25:12,803 INFO org.apache.cassandra.streaming.StreamOutSession: 
Streaming to /10.165.12.229
2013-07-23 16:25:12,816 INFO org.apache.cassandra.streaming.StreamOut: Stream 
context metadata 
[/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1-Data.db
 sections=1 progress=0/8 - 0%], 1 sstables.
2013-07-23 16:25:12,816 INFO org.apache.cassandra.streaming.StreamOutSession: 
Streaming to /10.164.44.90
2013-07-23 16:25:12,817 INFO org.apache.cassandra.streaming.StreamOut: Stream 
context metadata 
[/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1-Data.db
 sections=1 progress=0/8 - 0%], 1 sstables.
2013-07-23 16:25:12,817 INFO org.apache.cassandra.streaming.StreamOutSession: 
Streaming to /10.164.41.26
2013-07-23 16:25:12,876 INFO 
org.apache.cassandra.streaming.StreamReplyVerbHandler: Successfully sent 
/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1-Data.db
 to /10.164.44.90
2013-07-23 16:25:12,877 INFO org.apache.cassandra.streaming.FileStreamTask: 
Finished streaming session to /10.164.44.90
2013-07-23 16:25:12,877 INFO 
org.apache.cassandra.streaming.StreamReplyVerbHandler: Successfully sent 
/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1-Data.db
 to /10.164.41.26
2013-07-23 16:25:12,878 INFO org.apache.cassandra.streaming.FileStreamTask: 
Finished streaming session to /10.164.41.26
2013-07-23 16:25:12,882 INFO 
org.apache.cassandra.streaming.StreamReplyVerbHandler: Successfully sent 
/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1-Data.db
 to /10.165.12.229
2013-07-23 16:25:12,883 INFO org.apache.cassandra.streaming.FileStreamTask: 
Finished streaming session to /10.165.12.229
2013-07-23 16:25:12,905 INFO org.apache.cassandra.io.sstable.SSTableReader: 
Opening 
/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-ic-1
 (1144 bytes)
2013-07-23 16:25:12,907 INFO org.apache.cassandra.streaming.StreamOut: Stream 
context metadata 
[/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-ic-1-Data.db
 sections=1 progress=0/1144 - 0%], 1 sstables.
2013-07-23 16:25:12,907 INFO org.apache.cassandra.streaming.StreamOutSession: 
Streaming to /10.165.12.229
2013-07-23 16:25:12,908 INFO org.apache.cassandra.streaming.StreamOut: Stream 
context metadata 
[/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-ic-1-Data.db
 sections=1 progress=0/1144 - 0%], 1 sstables.
2013-07-23 16:25:12,908 INFO org.apache.cassandra.streaming.StreamOutSession: 
Streaming to /10.164.44.90
2013-07-23 16:25:12,909 INFO org.apache.cassandra.streaming.StreamOut: Stream 
context metadata 
[/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-ic-1-Data.db
 sections=1 progress=0/1144 - 0%], 1 sstables.
2013-07-23 16:25:12,910 INFO org.apache.cassandra.streaming.StreamOutSession: 
Streaming to /10.164.41.26


 BulkOutputFormat sometimes hangs when

[jira] [Commented] (CASSANDRA-5794) BulkOutputFormat sometimes hangs when loading small SSTables


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

Jim Zamata commented on CASSANDRA-5794:
---

Server logs after Killing hung client process:

DEBUG [Thread-17] 2013-07-23 16:54:53,914 FileUtils.java (line 110) Deleting 
en_oef_834_thrift-MessageData-tmp-ic-12-Data.db
DEBUG [Thread-17] 2013-07-23 16:54:53,914 FileUtils.java (line 110) Deleting 
en_oef_834_thrift-MessageData-tmp-ic-12-Filter.db
DEBUG [Thread-17] 2013-07-23 16:54:53,915 FileUtils.java (line 110) Deleting 
en_oef_834_thrift-MessageData-tmp-ic-12-Index.db
DEBUG [Thread-17] 2013-07-23 16:54:53,915 FileUtils.java (line 110) Deleting 
en_oef_834_thrift-MessageData-tmp-ic-12-TOC.txt
DEBUG [Thread-17] 2013-07-23 16:54:53,915 FileUtils.java (line 110) Deleting 
en_oef_834_thrift-MessageData-tmp-ic-12-CompressionInfo.db
DEBUG [Thread-17] 2013-07-23 16:54:53,915 SSTable.java (line 154) Deleted 
/mnt/cassandra/data/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-tmp-ic-12
ERROR [Thread-17] 2013-07-23 16:54:53,915 CassandraDaemon.java (line 192) 
Exception in thread Thread[Thread-17,5,main]
java.io.IOError: java.io.EOFException
at 
org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:255)
at 
org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:271)
at 
org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:228)
at edu.stanford.ppl.concurrent.SnapTreeMap.init(SnapTreeMap.java:453)
at 
org.apache.cassandra.db.AtomicSortedColumns$Holder.init(AtomicSortedColumns.java:310)
at 
org.apache.cassandra.db.AtomicSortedColumns.init(AtomicSortedColumns.java:79)
at 
org.apache.cassandra.db.AtomicSortedColumns.init(AtomicSortedColumns.java:50)
at 
org.apache.cassandra.db.AtomicSortedColumns$1.fromSorted(AtomicSortedColumns.java:63)
at 
org.apache.cassandra.db.SuperColumnSerializer.deserialize(SuperColumn.java:423)
at 
org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:80)
at 
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:250)
at 
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:185)
at 
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at 
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at 
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at 
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
Caused by: java.io.EOFException
at java.io.DataInputStream.readFully(Unknown Source)
at java.io.DataInputStream.readFully(Unknown Source)
at 
org.apache.cassandra.utils.BytesReadTracker.readFully(BytesReadTracker.java:94)
at 
org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:395)
at 
org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:371)
at 
org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:80)
at 
org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:251)
... 15 more


 BulkOutputFormat sometimes hangs when loading small SSTables
 

 Key: CASSANDRA-5794
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5794
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Affects Versions: 1.2.6
 Environment: linux (centos 6 server, ubuntu 13.04 client)
Reporter: Jim Zamata

 We have seen the bulk loader hang under some conditions.  This only seems to 
 occur when the last SSTable loaded is relatively small (1144 bytes in this 
 case). Turning on debug logging shows the StreamInSession starting to stream 
 a file, en_oef_834_thrift-MessageData-ic-1-Data.db below, and apparently 
 getting a Thrift transport error.  This loader was able to other files, some 
 of them even smaller, without any problems.
 The Thrift exception only appears in the debug logs, and apparently does not 
 cause the stream session to fail.  It just hangs the session on both the 
 server and the client until the client is killed.  When the client process is 
 killed, the server then gets an unexpected EOF exception.

--
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-5794) BulkOutputFormat sometimes hangs when loading small SSTables


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

Jim Zamata commented on CASSANDRA-5794:
---



Stack Trace showing request to stream file and Thrift errors:

DEBUG [Thread-16] 2013-07-23 16:25:34,081 IncomingTcpConnection.java (line 75) 
Connection version 6 from /10.171.6.226
DEBUG [Thread-16] 2013-07-23 16:25:34,082 StreamInSession.java (line 104) 
Adding file 
/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/atte
mpt_201307200231_0561_r_02_0/work/tmp/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-ic-1-Data.db
 to Stream Request queue
DEBUG [Thread-16] 2013-07-23 16:25:34,082 IncomingStreamReader.java (line 112) 
Receiving stream
DEBUG [Thread-16] 2013-07-23 16:25:34,082 IncomingStreamReader.java (line 113) 
Creating file for 
/mnt/cassandra/data/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageD
ata-tmp-ic-11-Data.db with 128 estimated keys
DEBUG [Thread-16] 2013-07-23 16:25:34,083 ColumnFamilyStore.java (line 862) 
Checking for sstables overlapping []
DEBUG [Thrift:40] 2013-07-23 16:25:34,092 StorageService.java (line 2578) 
computing ranges for -3074457345618258603, 3074457345618258602, 
9223372036854775807
DEBUG [Thread-17] 2013-07-23 16:25:34,117 IncomingTcpConnection.java (line 75) 
Connection version 6 from /10.171.6.226
DEBUG [Thread-17] 2013-07-23 16:25:34,117 StreamInSession.java (line 104) 
Adding file 
/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/atte
mpt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-ic-1-Data.db
 to Stream Request queue
DEBUG [Thread-17] 2013-07-23 16:25:34,117 IncomingStreamReader.java (line 112) 
Receiving stream
DEBUG [Thread-17] 2013-07-23 16:25:34,117 IncomingStreamReader.java (line 113) 
Creating file for 
/mnt/cassandra/data/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageD
ata-tmp-ic-12-Data.db with 128 estimated keys
DEBUG [Thread-17] 2013-07-23 16:25:34,118 ColumnFamilyStore.java (line 862) 
Checking for sstables overlapping []
DEBUG [Thrift:8] 2013-07-23 16:25:45,135 StorageService.java (line 2578) 
computing ranges for -3074457345618258603, 3074457345618258602, 
9223372036854775807
DEBUG [ScheduledTasks:1] 2013-07-23 16:26:05,875 LoadBroadcaster.java (line 87) 
Disseminating load info ...
DEBUG [Thrift:16] 2013-07-23 16:26:19,491 StorageService.java (line 2578) 
computing ranges for -3074457345618258603, 3074457345618258602, 
9223372036854775807
DEBUG [OptionalTasks:1] 2013-07-23 16:26:33,926 BatchlogManager.java (line 157) 
Started replayAllFailedBatches
DEBUG [MemtablePostFlusher:1] 2013-07-23 16:26:33,927 ColumnFamilyStore.java 
(line 693) forceFlush requested but everything is clean in batchlog
DEBUG [OptionalTasks:1] 2013-07-23 16:26:33,927 BatchlogManager.java (line 171) 
Finished replayAllFailedBatches
DEBUG [Thrift:1] 2013-07-23 16:26:35,638 StorageService.java (line 2578) 
computing ranges for -3074457345618258603, 3074457345618258602, 
9223372036854775807
DEBUG [Thrift:10] 2013-07-23 16:27:00,383 StorageService.java (line 2578) 
computing ranges for -3074457345618258603, 3074457345618258602, 
9223372036854775807
DEBUG [ScheduledTasks:1] 2013-07-23 16:27:05,876 LoadBroadcaster.java (line 87) 
Disseminating load info ...
DEBUG [Thrift:7] 2013-07-23 16:27:15,167 StorageService.java (line 2578) 
computing ranges for -3074457345618258603, 3074457345618258602, 
9223372036854775807
DEBUG [OptionalTasks:1] 2013-07-23 16:27:33,927 BatchlogManager.java (line 157) 
Started replayAllFailedBatches
DEBUG [MemtablePostFlusher:1] 2013-07-23 16:27:33,928 ColumnFamilyStore.java 
(line 693) forceFlush requested but everything is clean in batchlog
DEBUG [OptionalTasks:1] 2013-07-23 16:27:33,928 BatchlogManager.java (line 171) 
Finished replayAllFailedBatches
DEBUG [Thrift:42] 2013-07-23 16:27:48,489 CustomTThreadPoolServer.java (line 
209) Thrift transport error occurred during processing of message.
org.apache.thrift.transport.TTransportException
at 
org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
at 
org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:129)
at 
org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:101)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
at 
org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:378)
at 
org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:297)
at 
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:204)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:22)
at

git commit: change stream message priority(make received/retry proorities higher than complete).

2013-07-23 Thread yukim

Updated Branches:
  refs/heads/trunk 283b1a33b - 931be4803


change stream message priority(make received/retry proorities higher than 
complete).


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

Branch: refs/heads/trunk
Commit: 931be4803b1f21dc1605612364df128dce74a6ef
Parents: 283b1a3
Author: Yuki Morishita yu...@apache.org
Authored: Tue Jul 23 13:12:34 2013 -0500
Committer: Yuki Morishita yu...@apache.org
Committed: Tue Jul 23 13:12:34 2013 -0500

--
 .../org/apache/cassandra/streaming/messages/StreamMessage.java | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/931be480/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
--
diff --git 
a/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java 
b/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
index 11e9955..8ba731a 100644
--- a/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
+++ b/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
@@ -65,9 +65,9 @@ public abstract class StreamMessage
 {
 PREPARE(1, 5, PrepareMessage.serializer),
 FILE(2, 0, FileMessage.serializer),
-RECEIVED(3, 1, ReceivedMessage.serializer),
-RETRY(4, 1, RetryMessage.serializer),
-COMPLETE(5, 4, CompleteMessage.serializer),
+RECEIVED(3, 4, ReceivedMessage.serializer),
+RETRY(4, 4, RetryMessage.serializer),
+COMPLETE(5, 1, CompleteMessage.serializer),
 SESSION_FAILED(6, 5, SessionFailedMessage.serializer);
 
 public static Type get(byte type)

[jira] [Resolved] (CASSANDRA-5794) BulkOutputFormat sometimes hangs when loading small SSTables

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

Jim Zamata resolved CASSANDRA-5794.
---

Resolution: Not A Problem

These errors were due to regular columns being written to SSTables for super
column families.

BulkOutputFormat sometimes hangs when loading small SSTables

Key: CASSANDRA-5794
URL: https://issues.apache.org/jira/browse/CASSANDRA-5794
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 1.2.6
Environment: linux (centos 6 server, ubuntu 13.04 client)
Reporter: Jim Zamata

We have seen the bulk loader hang under some conditions. This only seems to
occur when the last SSTable loaded is relatively small (1144 bytes in this
case). Turning on debug logging shows the StreamInSession starting to stream
a file, en_oef_834_thrift-MessageData-ic-1-Data.db below, and apparently
getting a Thrift transport error. This loader was able to other files, some
of them even smaller, without any problems.
The Thrift exception only appears in the debug logs, and apparently does not
cause the stream session to fail. It just hangs the session on both the
server and the client until the client is killed. When the client process is
killed, the server then gets an unexpected EOF exception.

[jira] [Updated] (CASSANDRA-5614) W/O specified columns ASPCSI does not get notified of deletes

2013-07-23 Thread Sam Tunnicliffe (JIRA)


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

Sam Tunnicliffe updated CASSANDRA-5614:
---

Attachment: 0003-CASSANDRA-5614-Memtable-updates-with-RowTombstone-up.patch
0002-CASSANDRA-5614-LazilyCompactedRow-outputs-SSTables-a.patch
0001-CASSANDRA-5614-PreCompactedRow-updates-2i-correctly.patch

 W/O specified columns ASPCSI does not get notified of deletes
 -

 Key: CASSANDRA-5614
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5614
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Benjamin Coverston
Assignee: Sam Tunnicliffe
Priority: Minor
 Fix For: 1.2.7

 Attachments: 
 0001-CASSANDRA-5614-PreCompactedRow-updates-2i-correctly.patch, 
 0002-CASSANDRA-5614-LazilyCompactedRow-outputs-SSTables-a.patch, 
 0003-CASSANDRA-5614-Memtable-updates-with-RowTombstone-up.patch


 I'm working on a secondary index implementation based on the composite index 
 type.
 AbstractSimplePerColumnSecondaryIndex.java#delete is not called when CQL 
 delete statements do not specify columns.
 When I specify columns it is called. Pretty sure this is a bug.
 Setup:
 {code}
 cqlsh create KEYSPACE foo WITH replication = {'class': 'SimpleStrategy' , 
 'replication_factor': 1};
 cqlsh use foo;
 cqlsh:foo CREATE TABLE albums (artist text, album text, rating int, release 
 int, PRIMARY KEY (artist, album));
 cqlsh:foo CREATE INDEX ON albums (rating);
 {code}
 {code}
 cqlsh:foo insert into albums (artist, album, rating, release) VALUES 
 ('artist', 'album', 1, 2);
 {code}
 Does not get called here:
 {code}
 cqlsh:foo DELETE FROM albums where artist='artist' and album='album';
 {code}
 {code}
 cqlsh:foo insert into albums (artist, album, rating, release) VALUES 
 ('artist', 'album', 1, 2);
 {code}
 gets called here:
 {code}
 cqlsh:foo DELETE rating FROM albums where artist='artist' and album='album';
 {code}

--
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-5614) W/O specified columns ASPCSI does not get notified of deletes

2013-07-23 Thread Sam Tunnicliffe (JIRA)


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

Sam Tunnicliffe commented on CASSANDRA-5614:


First, we aren't doing the right thing in compaction either. Neither PCR or LCR 
clean up the index in the face of range tombstones, relying on repairs at read 
time to purge obsolete entries.
Looking into this, it also seems that PCR  LCR actually generate different 
SSTables. Although they're functionally equivalent, those that come from PCR 
don't have any columns covered by a RangeTombstone. SSTables generated by LCR 
do contain these redundant extra columns.

eg: if we have two SSTables:
{code}
[{key: 6e697276616e61,columns: 
[
[bleach:,,1374246211348000], 
[bleach:rating,4,1374246211348000], 
[bleach:release,1,1374246211348000], 
[nevermind:,,1374246211365000], 
[nevermind:rating,5,1374246211365000], 
[nevermind:release,2,1374246211365000]
]
}]

[{key: 6e697276616e61,columns: 
[
[nevermind,nevermind:!,1374246212053000,t,1374246212]
]
}]
{code}

When compacted with PCR we end up with in :
{code}
[{
key: 6e697276616e61,
columns: [
[bleach:,,1374246658577000], 
[bleach:rating,4,1374246658577000], 
[bleach:release,1,1374246658577000], 
[nevermind,nevermind:!,1374246659274000,t,1374246659]
]
}]
{code}

But with LCR we get:
{code}
[{
key: 6e697276616e61,
columns: [
[bleach:,,1374246211348000], 
[bleach:rating,4,1374246211348000], 
[bleach:release,1,1374246211348000], 
[nevermind,nevermind:!,1374246212053000,t,1374246212], 
[nevermind:,,1374246211365000], 
[nevermind:rating,5,1374246211365000], 
[nevermind:release,2,1374246211365000]
]
}]
{code}

The first patch fixes PCR to clean up indexes properly.  
The second fixes LCR so that it generates SSTables like PCR  fixes its index 
cleanup. 
The third adds the index cleanup for memtable updates with RT.

 W/O specified columns ASPCSI does not get notified of deletes
 -

 Key: CASSANDRA-5614
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5614
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Benjamin Coverston
Assignee: Sam Tunnicliffe
Priority: Minor
 Fix For: 1.2.7

 Attachments: 
 0001-CASSANDRA-5614-PreCompactedRow-updates-2i-correctly.patch, 
 0002-CASSANDRA-5614-LazilyCompactedRow-outputs-SSTables-a.patch, 
 0003-CASSANDRA-5614-Memtable-updates-with-RowTombstone-up.patch


 I'm working on a secondary index implementation based on the composite index 
 type.
 AbstractSimplePerColumnSecondaryIndex.java#delete is not called when CQL 
 delete statements do not specify columns.
 When I specify columns it is called. Pretty sure this is a bug.
 Setup:
 {code}
 cqlsh create KEYSPACE foo WITH replication = {'class': 'SimpleStrategy' , 
 'replication_factor': 1};
 cqlsh use foo;
 cqlsh:foo CREATE TABLE albums (artist text, album text, rating int, release 
 int, PRIMARY KEY (artist, album));
 cqlsh:foo CREATE INDEX ON albums (rating);
 {code}
 {code}
 cqlsh:foo insert into albums (artist, album, rating, release) VALUES 
 ('artist', 'album', 1, 2);
 {code}
 Does not get called here:
 {code}
 cqlsh:foo DELETE FROM albums where artist='artist' and album='album';
 {code}
 {code}
 cqlsh:foo insert into albums (artist, album, rating, release) VALUES 
 ('artist', 'album', 1, 2);
 {code}
 gets called here:
 {code}
 cqlsh:foo DELETE rating FROM albums where artist='artist' and album='album';
 {code}

--
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-4573) HSHA doesn't handle large messages gracefully

2013-07-23 Thread Tyler Hobbs (JIRA)


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

Tyler Hobbs commented on CASSANDRA-4573:


bq. Tyler, is this ticket still valid?

The changes for CASSANDRA-5582 probably make this invalid for 2.0, which I'm 
fine with.  I'll assign to myself, test against 2.0, close this ticket and open 
a new one for the 2.0 implementation if needed.

 HSHA doesn't handle large messages gracefully
 -

 Key: CASSANDRA-4573
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Tyler Hobbs
Assignee: Vijay
 Attachments: repro.py


 HSHA doesn't seem to enforce any kind of max message length, and when 
 messages are too large, it doesn't fail gracefully.
 With debug logs enabled, you'll see this:
 {{DEBUG 13:13:31,805 Unexpected state 16}}
 Which seems to mean that there's a SelectionKey that's valid, but isn't ready 
 for reading, writing, or accepting.
 Client-side, you'll get this thrift error (while trying to read a frame as 
 part of {{recv_batch_mutate}}):
 {{TTransportException: TSocket read 0 bytes}}

--
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] [Assigned] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully

2013-07-23 Thread Tyler Hobbs (JIRA)


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

Tyler Hobbs reassigned CASSANDRA-4573:
--

Assignee: Tyler Hobbs  (was: Vijay)

 HSHA doesn't handle large messages gracefully
 -

 Key: CASSANDRA-4573
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
 Attachments: repro.py


 HSHA doesn't seem to enforce any kind of max message length, and when 
 messages are too large, it doesn't fail gracefully.
 With debug logs enabled, you'll see this:
 {{DEBUG 13:13:31,805 Unexpected state 16}}
 Which seems to mean that there's a SelectionKey that's valid, but isn't ready 
 for reading, writing, or accepting.
 Client-side, you'll get this thrift error (while trying to read a frame as 
 part of {{recv_batch_mutate}}):
 {{TTransportException: TSocket read 0 bytes}}

--
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-5515) Track sstable coldness

2013-07-23 Thread Tyler Hobbs (JIRA)


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

Tyler Hobbs commented on CASSANDRA-5515:


bq. If we're not going to take the simple approach with a map, should we keep 
more data like this?

That's what I was thinking with the exception of the {{hour_ending_at}} column; 
I was thinking we would periodically overwrite a single read count row per 
sstable instead of tracking it in time-series fashion.  Are you specifically 
looking to have both recent read rates and total historic read rates?  If so, 
just using two counters would be lighter weight.  I don't foresee compaction 
strategies using more than the recent and total rates, but I suppose users 
might find full time series data useful.

 Track sstable coldness
 --

 Key: CASSANDRA-5515
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5515
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
 Fix For: 2.0.1

 Attachments: 0001-Track-row-read-counts-in-SSTR.patch


 Keeping a count of reads per-sstable would allow STCS to automatically ignore 
 cold data rather than recompacting it constantly with hot data, dramatically 
 reducing compaction load for typical time series applications and others with 
 time-correlated access patterns.  We would not need a separate age-tiered 
 compaction strategy.
 (This will really be useful in conjunction with CASSANDRA-5514.)

--
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-5789) Data not fully replicated with 2 nodes and replication factor 2

2013-07-23 Thread Brandon Williams (JIRA)


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

Brandon Williams updated CASSANDRA-5789:


Assignee: (was: Alex Zarutin)

Check if hints were generated and force hint delivery if so.

 Data not fully replicated with 2 nodes and replication factor 2
 ---

 Key: CASSANDRA-5789
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5789
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.2, 1.2.6
 Environment: Official Datastax Cassandra 1.2.6, running on Linux RHEL 
 6.2.  I've seen the same behavior with Cassandra 1.2.2.
 Sun Java 1.7.0_10-b18 64-bit
 Java heap settings: -Xms8192M -Xmx8192M -Xmn2048M
Reporter: James Lee

 I'm seeing a problem with a 2-node Cassandra test deployment, where it seems 
 that data isn't being replicated among the nodes as I would expect.
 The setup and test is as follows:
 - Two Cassandra nodes in the cluster (they each have themselves and the other 
 node as seeds in cassandra.yaml).
 - Create 40 keyspaces, each with simple replication strategy and 
 replication factor 2.
 - Populate 125,000 rows into each keyspace, using a pycassa client with a 
 connection pool pointed at both nodes.  These are populated with writes using 
 consistency level of 1.
 - Wait until nodetool on each node reports that there are no hinted handoffs 
 outstanding (see output below).
 - Do random reads of the rows in the keyspaces, again using a pycassa client 
 with a connection pool pointed at both nodes.  These are read using 
 consistency level 1.
 I'm finding that the vast majority of reads are successful, but a small 
 proportion (~0.1%) are returned as Not Found.  If I manually try to look up 
 those keys using cassandra-cli, I see that they are returned when querying 
 one of the nodes, but not when querying the other.  So it seems like some of 
 the rows have simply not been replicated, even though the write for these 
 rows was reported to the client as successful.
 If I reduce the rate at which the test tool initially writes data into the 
 database then I don't see any failed reads, so this seems like a load-related 
 issue.  My understanding is that if all writes were successful and there are 
 no pending hinted handoffs, then the data should be fully-replicated and 
 reads should return it (even with read and write consistency of 1).
 Here's the output from notetool on the two nodes:
 comet-mvs01:/dsc-cassandra-1.2.6# ./bin/nodetool tpstats
 Pool NameActive   Pending  Completed   Blocked  All 
 time blocked
 ReadStage 0 0  2 0
  0
 RequestResponseStage  0 0 878494 0
  0
 MutationStage 0 02869107 0
  0
 ReadRepairStage   0 0  0 0
  0
 ReplicateOnWriteStage 0 0  0 0
  0
 GossipStage   0 0   2208 0
  0
 AntiEntropyStage  0 0  0 0
  0
 MigrationStage0 0994 0
  0
 MemtablePostFlusher   0 0   4399 0
  0
 FlushWriter   0 0   2264 0
556
 MiscStage 0 0  0 0
  0
 commitlog_archiver0 0  0 0
  0
 InternalResponseStage 0 0153 0
  0
 HintedHandoff 0 0  2 0
  0
 Message type   Dropped
 RANGE_SLICE  0
 READ_REPAIR  0
 BINARY   0
 READ 0
 MUTATION 87655
 _TRACE   0
 REQUEST_RESPONSE 0
 comet-mvs02:/dsc-cassandra-1.2.6# ./bin/nodetool tpstats
 Pool NameActive   Pending  Completed   Blocked  All 
 time blocked
 ReadStage 0 0868 0
  0
 RequestResponseStage  0 03919665 0
  0
 MutationStage 0 08177325 0
  0
 ReadRepairStage   0 0113 0
  0
 ReplicateOnWriteStage 0 0  0 0
  0
 GossipStage   0 0

git commit: Fix exception text in SelectStatement

2013-07-23 Thread aleksey

Updated Branches:
  refs/heads/cassandra-1.2 66bd60590 - 25a46eae5


Fix exception text in SelectStatement


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

Branch: refs/heads/cassandra-1.2
Commit: 25a46eae5d1f6b48a490a4e77eb4df7c81a436d9
Parents: 66bd605
Author: Aleksey Yeschenko alek...@apache.org
Authored: Wed Jul 24 00:49:52 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed Jul 24 00:49:52 2013 +0300

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/25a46eae/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index 2a2b33a..8343d1e 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -1157,7 +1157,7 @@ public class SelectStatement implements CQLStatement
 
 // We don't support IN for indexed values (basically this 
would require supporting a form of OR)
 if (restriction.eqValues.size()  1)
-throw new InvalidRequestException(Cannot use IN 
operator on column not part of the PRIMARY KEY);
+throw new InvalidRequestException(Cannot use IN 
operator on column not part of the partition key);
 
 if (indexedNames.contains(entry.getKey().name.key))
 {

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

2013-07-23 Thread aleksey

Merge branch 'cassandra-1.2' into trunk

Conflicts:
src/java/org/apache/cassandra/cql3/statements/SelectStatement.java


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

Branch: refs/heads/trunk
Commit: 7b841aade2c7136b00f17815aa293fdbcdfac1dc
Parents: 931be48 25a46ea
Author: Aleksey Yeschenko alek...@apache.org
Authored: Wed Jul 24 00:57:03 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed Jul 24 00:57:03 2013 +0300

--

--

[1/2] git commit: Fix exception text in SelectStatement

2013-07-23 Thread aleksey

Updated Branches:
  refs/heads/trunk 931be4803 - 7b841aade


Fix exception text in SelectStatement


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

Branch: refs/heads/trunk
Commit: 25a46eae5d1f6b48a490a4e77eb4df7c81a436d9
Parents: 66bd605
Author: Aleksey Yeschenko alek...@apache.org
Authored: Wed Jul 24 00:49:52 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed Jul 24 00:49:52 2013 +0300

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/25a46eae/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index 2a2b33a..8343d1e 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -1157,7 +1157,7 @@ public class SelectStatement implements CQLStatement
 
 // We don't support IN for indexed values (basically this 
would require supporting a form of OR)
 if (restriction.eqValues.size()  1)
-throw new InvalidRequestException(Cannot use IN 
operator on column not part of the PRIMARY KEY);
+throw new InvalidRequestException(Cannot use IN 
operator on column not part of the partition key);
 
 if (indexedNames.contains(entry.getKey().name.key))
 {

[jira] [Assigned] (CASSANDRA-5794) BulkOutputFormat sometimes hangs when loading small SSTables

2013-07-23 Thread Nick Bailey (JIRA)


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

Nick Bailey reassigned CASSANDRA-5794:
--

Assignee: Nick Bailey

 BulkOutputFormat sometimes hangs when loading small SSTables
 

 Key: CASSANDRA-5794
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5794
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Affects Versions: 1.2.6
 Environment: linux (centos 6 server, ubuntu 13.04 client)
Reporter: Jim Zamata
Assignee: Nick Bailey

 We have seen the bulk loader hang under some conditions.  This only seems to 
 occur when the last SSTable loaded is relatively small (1144 bytes in this 
 case). Turning on debug logging shows the StreamInSession starting to stream 
 a file, en_oef_834_thrift-MessageData-ic-1-Data.db below, and apparently 
 getting a Thrift transport error.  This loader was able to other files, some 
 of them even smaller, without any problems.
 The Thrift exception only appears in the debug logs, and apparently does not 
 cause the stream session to fail.  It just hangs the session on both the 
 server and the client until the client is killed.  When the client process is 
 killed, the server then gets an unexpected EOF exception.

--
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-5795) now() is being rejected in INSERTs when inside collections

2013-07-23 Thread Aleksey Yeschenko (JIRA)

Aleksey Yeschenko created CASSANDRA-5795:


 Summary: now() is being rejected in INSERTs when inside collections
 Key: CASSANDRA-5795
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5795
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.6
Reporter: Aleksey Yeschenko
Assignee: Sylvain Lebresne


Lists, Sets and Maps reject NonTerminal terms in prepare:

{code}
if (t instanceof Term.NonTerminal)
throw new InvalidRequestException(String.format(Invalid 
list literal for %s: bind variables are not supported inside collection 
literals, receiver));
{code}

and now() is instanceof NonTerminal since CASSANDRA-5616, hence

{noformat}
cqlsh:test insert into demo (id, timeuuids) values (0, [now()]);
Bad Request: Invalid list literal for tus: bind variables are not supported 
inside collection literals
{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

[jira] [Commented] (CASSANDRA-5614) W/O specified columns ASPCSI does not get notified of deletes


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

Jonathan Ellis commented on CASSANDRA-5614:
---

Thanks! Do you have a github branch for this?

 W/O specified columns ASPCSI does not get notified of deletes
 -

 Key: CASSANDRA-5614
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5614
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Benjamin Coverston
Assignee: Sam Tunnicliffe
Priority: Minor
 Fix For: 1.2.7

 Attachments: 
 0001-CASSANDRA-5614-PreCompactedRow-updates-2i-correctly.patch, 
 0002-CASSANDRA-5614-LazilyCompactedRow-outputs-SSTables-a.patch, 
 0003-CASSANDRA-5614-Memtable-updates-with-RowTombstone-up.patch


 I'm working on a secondary index implementation based on the composite index 
 type.
 AbstractSimplePerColumnSecondaryIndex.java#delete is not called when CQL 
 delete statements do not specify columns.
 When I specify columns it is called. Pretty sure this is a bug.
 Setup:
 {code}
 cqlsh create KEYSPACE foo WITH replication = {'class': 'SimpleStrategy' , 
 'replication_factor': 1};
 cqlsh use foo;
 cqlsh:foo CREATE TABLE albums (artist text, album text, rating int, release 
 int, PRIMARY KEY (artist, album));
 cqlsh:foo CREATE INDEX ON albums (rating);
 {code}
 {code}
 cqlsh:foo insert into albums (artist, album, rating, release) VALUES 
 ('artist', 'album', 1, 2);
 {code}
 Does not get called here:
 {code}
 cqlsh:foo DELETE FROM albums where artist='artist' and album='album';
 {code}
 {code}
 cqlsh:foo insert into albums (artist, album, rating, release) VALUES 
 ('artist', 'album', 1, 2);
 {code}
 gets called here:
 {code}
 cqlsh:foo DELETE rating FROM albums where artist='artist' and album='album';
 {code}

--
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-5796) Cqlsh should return a result in the case of a CAS INSERT/UPDATE

Michaël Figuière created CASSANDRA-5796:
---

 Summary: Cqlsh should return a result in the case of a CAS 
INSERT/UPDATE
 Key: CASSANDRA-5796
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5796
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 2.0 beta 1
Reporter: Michaël Figuière
Priority: Minor


Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for 
regular INSERT/UPDATE statements, that is without displaying anything is there 
were no error.

Ideally it should display the ResultSet returned by these CAS statements as 
defined in CASSANDRA-5619.

--
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-5796) Cqlsh should return a result in the case of a CAS INSERT/UPDATE


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

Michaël Figuière updated CASSANDRA-5796:


Description: 
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for 
regular {{INSERT/UPDATE}} statements, that is without displaying anything is 
there were no error.

Ideally it should display the ResultSet returned by these CAS statements as 
defined in CASSANDRA-5619.

  was:
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for 
regular INSERT/UPDATE statements, that is without displaying anything is there 
were no error.

Ideally it should display the ResultSet returned by these CAS statements as 
defined in CASSANDRA-5619.


 Cqlsh should return a result in the case of a CAS INSERT/UPDATE
 ---

 Key: CASSANDRA-5796
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5796
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 2.0 beta 1
Reporter: Michaël Figuière
Priority: Minor

 Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for 
 regular {{INSERT/UPDATE}} statements, that is without displaying anything is 
 there were no error.
 Ideally it should display the ResultSet returned by these CAS statements as 
 defined in CASSANDRA-5619.

--
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-5796) Cqlsh should return a result in the case of a CAS INSERT/UPDATE


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

Michaël Figuière updated CASSANDRA-5796:


Description: 
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for 
regular {{INSERT/UPDATE}} statements, that if without displaying anything is 
there were no error.

Ideally it should display the ResultSet returned by these CAS statements as 
defined in CASSANDRA-5619.

  was:
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for 
regular {{INSERT/UPDATE}} statements, that is without displaying anything is 
there were no error.

Ideally it should display the ResultSet returned by these CAS statements as 
defined in CASSANDRA-5619.


 Cqlsh should return a result in the case of a CAS INSERT/UPDATE
 ---

 Key: CASSANDRA-5796
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5796
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 2.0 beta 1
Reporter: Michaël Figuière
Priority: Minor

 Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for 
 regular {{INSERT/UPDATE}} statements, that if without displaying anything is 
 there were no error.
 Ideally it should display the ResultSet returned by these CAS statements as 
 defined in CASSANDRA-5619.

--
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-5796) Cqlsh should return a result in the case of a CAS INSERT/UPDATE


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

Michaël Figuière updated CASSANDRA-5796:


Description: 
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for 
regular {{INSERT/UPDATE}} statements, that is without displaying anything if 
there were no error.

Ideally it should display the ResultSet returned by these CAS statements as 
defined in CASSANDRA-5619.

  was:
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for 
regular {{INSERT/UPDATE}} statements, that if without displaying anything is 
there were no error.

Ideally it should display the ResultSet returned by these CAS statements as 
defined in CASSANDRA-5619.


 Cqlsh should return a result in the case of a CAS INSERT/UPDATE
 ---

 Key: CASSANDRA-5796
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5796
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 2.0 beta 1
Reporter: Michaël Figuière
Priority: Minor

 Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for 
 regular {{INSERT/UPDATE}} statements, that is without displaying anything if 
 there were no error.
 Ideally it should display the ResultSet returned by these CAS statements as 
 defined in CASSANDRA-5619.

--
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-5797) DC-local CAS


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

Jonathan Ellis commented on CASSANDRA-5797:
---

Not sure what CQL syntax for this is.  Is it protocol level the way CL is?

 DC-local CAS
 

 Key: CASSANDRA-5797
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5797
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 2.0
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 2.0.1


 For two-datacenter deployments where the second DC is strictly for disaster 
 failover, it would be useful to restrict CAS to a single DC to avoid cross-DC 
 round trips.
 (This would require manually truncating {{system.paxos}} when failing over.)

--
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-5797) DC-local CAS

Jonathan Ellis created CASSANDRA-5797:
-

 Summary: DC-local CAS
 Key: CASSANDRA-5797
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5797
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 2.0
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 2.0.1


For two-datacenter deployments where the second DC is strictly for disaster 
failover, it would be useful to restrict CAS to a single DC to avoid cross-DC 
round trips.

(This would require manually truncating {{system.paxos}} when failing over.)

--
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-5798) Cqlsh should support multiline comments

Michaël Figuière created CASSANDRA-5798:
---

 Summary: Cqlsh should support multiline comments
 Key: CASSANDRA-5798
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5798
 Project: Cassandra
  Issue Type: Improvement
Reporter: Michaël Figuière
Priority: Trivial


Right now cqlsh doesn't support multiline comments that are available in the 
CQL grammar:

{quote}
{code}
MULTILINE_COMMENT
: '/*' .* '*/' { $channel = HIDDEN; }
;
{code}
{quote}

These should be supported both in file and interactive mode (where copy pasting 
large chunks of CQL scripts containing such comments might be convenient).

--
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-5515) Track sstable coldness


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

Jonathan Ellis commented on CASSANDRA-5515:
---

Maybe get fancy and do a reservoir-sampling histogram?  Metrics makes that easy.

 Track sstable coldness
 --

 Key: CASSANDRA-5515
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5515
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
 Fix For: 2.0.1

 Attachments: 0001-Track-row-read-counts-in-SSTR.patch


 Keeping a count of reads per-sstable would allow STCS to automatically ignore 
 cold data rather than recompacting it constantly with hot data, dramatically 
 reducing compaction load for typical time series applications and others with 
 time-correlated access patterns.  We would not need a separate age-tiered 
 compaction strategy.
 (This will really be useful in conjunction with CASSANDRA-5514.)

--
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-5798) Cqlsh should support multiline comments