date:20130830


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

DOAN DuyHai updated CASSANDRA-4851:
---

Comment: was deleted

(was: Big +10 for this feature

Right now I am preparing some slides for a talk and tutorial on Cassandra to 
convince people switching from Thrift to CQL3. However I am facing serious 
issue because of the limitation of CQL3 not being able to allow inequality on 
more than 1 clustered component at a time.

 My example is quite trivial

{code:sql}
 CREATE TABLE comment_index_by_rating
 (
songId uuid,
rating int,  // rating is integer from 1 to 10
date uuid, // date of the comment
comment text, //comment message itself 
userLogin text, //login of the user who posts the comment
PRIMARY KEY (songId,rating,date)
 )
{code}


 I would like to paginate over comment so the first query would be

{code:sql}
 SELECT * FROM comment_index_by_rating WHERE songId =  ORDER BY rating DESC 
LIMIT 10; // fetch first 10 comments
{code}

 The following queries would be:

{code:sql}
 SELECT * FROM comment_index_by_rating WHERE songId =  AND rating = 
{rating_of_last_comment_of_previous_batch} AND date = 
{date_of_last_comment_of_previous_batch}
{code}

 Right now it is just IMPOSSIBLE to paginate like this, which is PITA.

 I know that there is already jira 
https://issues.apache.org/jira/browse/CASSANDRA-4415  which is a really good 
idea but the issue raised above is *beyond the scope of just paging data*.

 People are using more and more compound primary keys to model with Cassandra 
and they should be able to do slice queries with inequality from all compound 
components.

 There are lots of use cases where such usage is required

For example indexing daily metrics
{code:sql}
CREATE TABLE daily_metrics
(
  day int, // day in MMDD format
  hour int, 
  minute int,
  second int,
  metrics blob, 
  PRIMARY KEY (day, hour, minute, second)
)
{code}

 I should be able to grep all metrics from a range of date

  // select all metrics from 8:30am to 10am
 {code:sql}
 SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 8 AND 
minute = 30 and hour = 10
 {code}

)

 CQL3: improve support for paginating over composites
 

 Key: CASSANDRA-4851
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4851
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Priority: Minor

 Consider the following table:
 {noformat}
 CREATE TABLE test (
 k int,
 c1 int,
 c2 int,
 PRIMARY KEY (k, c1, c2)
 )
 {noformat}
 with the following data:
 {noformat}
 k | c1 | c2
 
 0 | 0  | 0
 0 | 0  | 1
 0 | 1  | 0
 0 | 1  | 1
 {noformat}
 Currently, CQL3 allows to slice over either c1 or c2:
 {noformat}
 SELECT * FROM test WHERE k = 0 AND c1  0 AND c1  2
 SELECT * FROM test WHERE k = 0 AND c1 = 1 AND c2  0 AND c2  2
 {noformat}
 but you cannot express a query that return the 3 last records. Indeed, for 
 that you would need to do a query like say:
 {noformat}
 SELECT * FROM test WHERE k = 0 AND ((c1 = 0 AND c2  0) OR c2  0)
 {noformat}
 but we don't support that.
 This can make it hard to paginate over say all records for {{k = 0}} (I'm 
 saying can because if the value for c2 cannot be very large, an easy 
 workaround could be to paginate by entire value of c1, which you can do).
 For the case where you only paginate to avoid OOMing on a query, 
 CASSANDRA-4415 will that and is probably the best solution. However, there 
 may be case where the pagination is say user (as in, the user of your 
 application) triggered.
 I note that one solution would be to add the OR support at least in case like 
 the one above. That's definitively doable but on the other side, we won't be 
 able to support full-blown OR, so it may not be very natural that we support 
 seemingly random combination of OR and not others.
 Another solution would be to allow the following syntax:
 {noformat}
 SELECT * FROM test WHERE k = 0 AND (c1, c2)  (0, 0)
 {noformat}
 which would literally mean that you want records where the values of c1 and 
 c2 taken as a tuple is lexicographically greater than the tuple (0, 0). This 
 is less SQL-like (though maybe some SQL store have that, it's a fairly thing 
 to have imo?), but would be much simpler to implement and probably to use too.

--
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-4851) CQL3: improve support for paginating over composites


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

DOAN DuyHai commented on CASSANDRA-4851:


Big +10 for this issue

Right now I am preparing some slides for a talk and tutorial on Cassandra to 
convince people switching from Thrift to CQL3. However I am facing serious 
issue because of the limitation of CQL3 not being able to allow inequality on 
more than 1 clustered component at a time.

 My example is quite trivial. Let's consider a rating and comment wide row for 
songs

{code:sql}
 CREATE TABLE comment_index_by_rating
 (
songId uuid,
rating int,  // rating is integer from 1 to 10
date uuid, // date of the comment
comment text, //comment message itself 
userLogin text, //login of the user who posts the comment
PRIMARY KEY (songId,rating,date)
 )
{code}


 I would like to paginate over comment so the first query would be

{code:sql}
 SELECT * FROM comment_index_by_rating WHERE songId =  ORDER BY rating DESC 
LIMIT 10; // fetch first 10 comments
{code}

 The following queries would be:

{code:sql}
 SELECT * FROM comment_index_by_rating WHERE songId =  AND rating = 
{rating_of_last_comment_of_previous_batch} AND date = 
{date_of_last_comment_of_previous_batch}
{code}

 Right now it is just IMPOSSIBLE to paginate like this, which is PITA.

 I know that there is already jira 
[CASSANDRA-4415|https://issues.apache.org/jira/browse/CASSANDRA-4415] which is 
a really good idea but the issue raised above is *beyond the scope of just 
paging data*.

 People are using more and more compound primary keys to model with Cassandra 
and they should be able to do slice queries with inequality from all compound 
components.

 There are lots of use cases where such usage is required

For example indexing daily metrics
{code:sql}
CREATE TABLE daily_metrics
(
  day int, // day in MMDD format
  hour int, 
  minute int,
  second int,
  metrics blob, 
  PRIMARY KEY (day, hour, minute, second)
)
{code}

 I should be able to grep all metrics from a range of date

  // select all metrics from 8:30am to 10am
 {code:sql}
 SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 8 AND 
minute = 30 and hour = 10
 {code}


 CQL3: improve support for paginating over composites
 

 Key: CASSANDRA-4851
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4851
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Priority: Minor

 Consider the following table:
 {noformat}
 CREATE TABLE test (
 k int,
 c1 int,
 c2 int,
 PRIMARY KEY (k, c1, c2)
 )
 {noformat}
 with the following data:
 {noformat}
 k | c1 | c2
 
 0 | 0  | 0
 0 | 0  | 1
 0 | 1  | 0
 0 | 1  | 1
 {noformat}
 Currently, CQL3 allows to slice over either c1 or c2:
 {noformat}
 SELECT * FROM test WHERE k = 0 AND c1  0 AND c1  2
 SELECT * FROM test WHERE k = 0 AND c1 = 1 AND c2  0 AND c2  2
 {noformat}
 but you cannot express a query that return the 3 last records. Indeed, for 
 that you would need to do a query like say:
 {noformat}
 SELECT * FROM test WHERE k = 0 AND ((c1 = 0 AND c2  0) OR c2  0)
 {noformat}
 but we don't support that.
 This can make it hard to paginate over say all records for {{k = 0}} (I'm 
 saying can because if the value for c2 cannot be very large, an easy 
 workaround could be to paginate by entire value of c1, which you can do).
 For the case where you only paginate to avoid OOMing on a query, 
 CASSANDRA-4415 will that and is probably the best solution. However, there 
 may be case where the pagination is say user (as in, the user of your 
 application) triggered.
 I note that one solution would be to add the OR support at least in case like 
 the one above. That's definitively doable but on the other side, we won't be 
 able to support full-blown OR, so it may not be very natural that we support 
 seemingly random combination of OR and not others.
 Another solution would be to allow the following syntax:
 {noformat}
 SELECT * FROM test WHERE k = 0 AND (c1, c2)  (0, 0)
 {noformat}
 which would literally mean that you want records where the values of c1 and 
 c2 taken as a tuple is lexicographically greater than the tuple (0, 0). This 
 is less SQL-like (though maybe some SQL store have that, it's a fairly thing 
 to have imo?), but would be much simpler to implement and probably to use too.

--
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 Push Summary

2013-08-30 Thread slebresne

Updated Tags:  refs/tags/1.2.9-tentative [deleted] 6164d011e

Git Push Summary

2013-08-30 Thread slebresne

Updated Tags:  refs/tags/cassandra-1.2.9 [created] bad1c648c

svn commit: r1518938 - in /cassandra/site: publish/download/index.html publish/index.html src/settings.py

2013-08-30 Thread slebresne

Author: slebresne
Date: Fri Aug 30 11:13:47 2013
New Revision: 1518938

URL: http://svn.apache.org/r1518938
Log:
Update website for 1.2.9 release

Modified:
cassandra/site/publish/download/index.html
cassandra/site/publish/index.html
cassandra/site/src/settings.py

Modified: cassandra/site/publish/download/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1518938r1=1518937r2=1518938view=diff
==
--- cassandra/site/publish/download/index.html (original)
+++ cassandra/site/publish/download/index.html Fri Aug 30 11:13:47 2013
@@ -49,8 +49,8 @@
   Cassandra releases include the core server, the a 
href=http://wiki.apache.org/cassandra/NodeTool;nodetool/a administration 
command-line interface, and a development shell (a 
href=http://cassandra.apache.org/doc/cql/CQL.html;ttcqlsh/tt/a and the 
old ttcassandra-cli/tt).
 
   p
-  The latest stable release of Apache Cassandra is 1.2.8
-  (released on 2013-07-28).  iIf you're just
+  The latest stable release of Apache Cassandra is 1.2.9
+  (released on 2013-08-30).  iIf you're just
   starting out, download this one./i
   /p
 
@@ -59,13 +59,13 @@
   ul
 li
 a class=filename 
-   
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.2.8/apache-cassandra-1.2.8-bin.tar.gz;
+   
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.2.9/apache-cassandra-1.2.9-bin.tar.gz;
onclick=javascript: 
pageTracker._trackPageview('/clicks/binary_download');
-  apache-cassandra-1.2.8-bin.tar.gz
+  apache-cassandra-1.2.9-bin.tar.gz
 /a
-[a 
href=http://www.apache.org/dist/cassandra/1.2.8/apache-cassandra-1.2.8-bin.tar.gz.asc;PGP/a]
-[a 
href=http://www.apache.org/dist/cassandra/1.2.8/apache-cassandra-1.2.8-bin.tar.gz.md5;MD5/a]
-[a 
href=http://www.apache.org/dist/cassandra/1.2.8/apache-cassandra-1.2.8-bin.tar.gz.sha1;SHA1/a]
+[a 
href=http://www.apache.org/dist/cassandra/1.2.9/apache-cassandra-1.2.9-bin.tar.gz.asc;PGP/a]
+[a 
href=http://www.apache.org/dist/cassandra/1.2.9/apache-cassandra-1.2.9-bin.tar.gz.md5;MD5/a]
+[a 
href=http://www.apache.org/dist/cassandra/1.2.9/apache-cassandra-1.2.9-bin.tar.gz.sha1;SHA1/a]
 /li
 li
 a href=http://wiki.apache.org/cassandra/DebianPackaging;Debian 
installation instructions/a
@@ -169,13 +169,13 @@
   ul
 li
 a class=filename 
-   
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.2.8/apache-cassandra-1.2.8-src.tar.gz;
+   
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.2.9/apache-cassandra-1.2.9-src.tar.gz;
onclick=javascript: 
pageTracker._trackPageview('/clicks/source_download');
-  apache-cassandra-1.2.8-src.tar.gz
+  apache-cassandra-1.2.9-src.tar.gz
 /a
-[a 
href=http://www.apache.org/dist/cassandra/1.2.8/apache-cassandra-1.2.8-src.tar.gz.asc;PGP/a]
-[a 
href=http://www.apache.org/dist/cassandra/1.2.8/apache-cassandra-1.2.8-src.tar.gz.md5;MD5/a]
-[a 
href=http://www.apache.org/dist/cassandra/1.2.8/apache-cassandra-1.2.8-src.tar.gz.sha1;SHA1/a]
+[a 
href=http://www.apache.org/dist/cassandra/1.2.9/apache-cassandra-1.2.9-src.tar.gz.asc;PGP/a]
+[a 
href=http://www.apache.org/dist/cassandra/1.2.9/apache-cassandra-1.2.9-src.tar.gz.md5;MD5/a]
+[a 
href=http://www.apache.org/dist/cassandra/1.2.9/apache-cassandra-1.2.9-src.tar.gz.sha1;SHA1/a]
 /li
   
 li

Modified: cassandra/site/publish/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/index.html?rev=1518938r1=1518937r2=1518938view=diff
==
--- cassandra/site/publish/index.html (original)
+++ cassandra/site/publish/index.html Fri Aug 30 11:13:47 2013
@@ -76,8 +76,8 @@
   h2Download/h2
   div class=inner rc
 p
-The latest release is b1.2.8/b
-span class=relnotes(a 
href=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-1.2.8;Changes/a)/span
+The latest release is b1.2.9/b
+span class=relnotes(a 
href=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-1.2.9;Changes/a)/span
 /p
 
 pa class=filename href=/download/Download options/a/p

Modified: cassandra/site/src/settings.py
URL: 
http://svn.apache.org/viewvc/cassandra/site/src/settings.py?rev=1518938r1=1518937r2=1518938view=diff
==
--- cassandra/site/src/settings.py (original)
+++ cassandra/site/src/settings.py Fri Aug 30 11:13:47 2013
@@ -98,8 +98,8 @@ class CassandraDef(object):
 veryoldstable_version = '1.0.12'
 veryoldstable_release_date = '2012-10-04'
 veryoldstable_exists = True
-stable_version = '1.2.8'
-stable_release_date = '2013-07-28'
+stable_version = '1.2.9'
+stable_release_date = '2013-08-30'

[jira] [Issue Comment Deleted] (CASSANDRA-4851) CQL3: improve support for paginating over composites


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

DOAN DuyHai updated CASSANDRA-4851:
---

Comment: was deleted

(was: Big +10 for this issue

Right now I am preparing some slides for a talk and tutorial on Cassandra to 
convince people switching from Thrift to CQL3. However I am facing serious 
issue because of the limitation of CQL3 not being able to allow inequality on 
more than 1 clustered component at a time.

 My example is quite trivial. Let's consider a rating and comment wide row for 
songs

{code:sql}
 CREATE TABLE comment_index_by_rating
 (
songId uuid,
rating int,  // rating is integer from 1 to 10
date uuid, // date of the comment
comment text, //comment message itself 
userLogin text, //login of the user who posts the comment
PRIMARY KEY (songId,rating,date)
 )
{code}


 I would like to paginate over comment so the first query would be

{code:sql}
 SELECT * FROM comment_index_by_rating WHERE songId =  ORDER BY rating DESC 
LIMIT 10; // fetch first 10 comments
{code}

 The following queries would be:

{code:sql}
 SELECT * FROM comment_index_by_rating WHERE songId =  AND rating = 
{rating_of_last_comment_of_previous_batch} AND date = 
{date_of_last_comment_of_previous_batch}
{code}

 Right now it is just IMPOSSIBLE to paginate like this, which is PITA.

 I know that there is already jira 
[CASSANDRA-4415|https://issues.apache.org/jira/browse/CASSANDRA-4415] which is 
a really good idea but the issue raised above is *beyond the scope of just 
paging data*.

 People are using more and more compound primary keys to model with Cassandra 
and they should be able to do slice queries with inequality from all compound 
components.

 There are lots of use cases where such usage is required

For example indexing daily metrics
{code:sql}
CREATE TABLE daily_metrics
(
  day int, // day in MMDD format
  hour int, 
  minute int,
  second int,
  metrics blob, 
  PRIMARY KEY (day, hour, minute, second)
)
{code}

 I should be able to grep all metrics from a range of date

  // select all metrics from 8:30am to 10am
 {code:sql}
 SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 8 AND 
minute = 30 and hour = 10
 {code}
)

 CQL3: improve support for paginating over composites
 

 Key: CASSANDRA-4851
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4851
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Priority: Minor

 Consider the following table:
 {noformat}
 CREATE TABLE test (
 k int,
 c1 int,
 c2 int,
 PRIMARY KEY (k, c1, c2)
 )
 {noformat}
 with the following data:
 {noformat}
 k | c1 | c2
 
 0 | 0  | 0
 0 | 0  | 1
 0 | 1  | 0
 0 | 1  | 1
 {noformat}
 Currently, CQL3 allows to slice over either c1 or c2:
 {noformat}
 SELECT * FROM test WHERE k = 0 AND c1  0 AND c1  2
 SELECT * FROM test WHERE k = 0 AND c1 = 1 AND c2  0 AND c2  2
 {noformat}
 but you cannot express a query that return the 3 last records. Indeed, for 
 that you would need to do a query like say:
 {noformat}
 SELECT * FROM test WHERE k = 0 AND ((c1 = 0 AND c2  0) OR c2  0)
 {noformat}
 but we don't support that.
 This can make it hard to paginate over say all records for {{k = 0}} (I'm 
 saying can because if the value for c2 cannot be very large, an easy 
 workaround could be to paginate by entire value of c1, which you can do).
 For the case where you only paginate to avoid OOMing on a query, 
 CASSANDRA-4415 will that and is probably the best solution. However, there 
 may be case where the pagination is say user (as in, the user of your 
 application) triggered.
 I note that one solution would be to add the OR support at least in case like 
 the one above. That's definitively doable but on the other side, we won't be 
 able to support full-blown OR, so it may not be very natural that we support 
 seemingly random combination of OR and not others.
 Another solution would be to allow the following syntax:
 {noformat}
 SELECT * FROM test WHERE k = 0 AND (c1, c2)  (0, 0)
 {noformat}
 which would literally mean that you want records where the values of c1 and 
 c2 taken as a tuple is lexicographically greater than the tuple (0, 0). This 
 is less SQL-like (though maybe some SQL store have that, it's a fairly thing 
 to have imo?), but would be much simpler to implement and probably to use too.

--
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-5955) The native protocol server can trigger a Netty bug

2013-08-30 Thread Sylvain Lebresne (JIRA)

Sylvain Lebresne created CASSANDRA-5955:
---

 Summary: The native protocol server can trigger a Netty bug
 Key: CASSANDRA-5955
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5955
 Project: Cassandra
  Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
 Fix For: 1.2.10


The patch from CASSANDRA-5926 did fix the original deadlock, but unfortunately 
we can now run into a netty bug (with MemoryAwareThreadPoolExecutor): 
https://github.com/netty/netty/issues/1310.

That bug has been fixed in netty 3.6.6 but we're currently using an older 
version (3.5.9). So we should just upgrade our dependency to 3.6.6. 

--
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] [Resolved] (CASSANDRA-5926) The native protocol server can deadlock

2013-08-30 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne resolved CASSANDRA-5926.
-

Resolution: Fixed

Let me re-close this since the committed did fix the original deadlock. It's
obviously now unfortunate that we're running into a netty bug, but since 1.2.9
has shipped, I've opened a separate issue (CASSANDRA-5955) to upgrade our
dependency.

The native protocol server can deadlock
---

Key: CASSANDRA-5926
URL: https://issues.apache.org/jira/browse/CASSANDRA-5926
Project: Cassandra
Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Fix For: 1.2.9

Attachments: 5926.txt, stack

Until CASSANDRA-5239 (i.e. since StorageProxy is blocking), the native
protocol server needs to use a thread per request being processed. For that,
it currently use a DebuggableThreadPoolExecutor, but with a limited queue.
The rational being that we don't want to OOM if a client overwhelm the
server. Rather, we prefer blocking (which DTPE gives us) on the submission of
new request by the netty worker threads when all threads are busy.
However, as it happens, when netty sends back a response to a query, there is
cases where some events (technically, InterestChanged and WriteComplete
events) are send up the pipeline. And those event are submitted on the
request executor as other requests. Long story short, a request thread can
end blocking on the submission to its own executor, hence deadlocking.
The simplest solution is probably to reuse MemoryAwareThreadPoolExecutor from
netty rather that our own DTPE as it also allow to block task submission when
all threads are busy but knows not to block it's own internal events.

--
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-5956) Allow filtering on more than 1 clustered components

DOAN DuyHai created CASSANDRA-5956:
--

 Summary: Allow filtering on more than 1 clustered components
 Key: CASSANDRA-5956
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5956
 Project: Cassandra
  Issue Type: Improvement
  Components: API, Core
Reporter: DOAN DuyHai


Right now I am preparing some slides for a talk and tutorial on Cassandra to 
convince people switching from Thrift to CQL3. However I am facing serious 
issue because of the limitation of CQL3 not being able to allow inequality on 
more than 1 clustered component at a time.

 My example is quite trivial. Let's consider a table to collect daily metrics

{code:sql}
CREATE TABLE daily_metrics
(
  day int, // day in MMDD format
  hour int, 
  minute int,
  second int,
  metrics blob, 
  PRIMARY KEY (day, hour, minute, second)
)
{code}

 I should be able to grep all metrics from a range of date

  // select all metrics from 8:30am to 10am
 {code:sql}
 SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 8 AND 
minute = 30 and hour = 10
 {code}

 // select all metrics of the day from 6:30pm
 {code:sql}
 SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 18 AND 
minute = 30 
 {code}

 
 Right now it is just IMPOSSIBLE to do this kind of query with CQL3, which is 
PITA. We always get the error message

{quote}
Bad Request: PRIMARY KEY part minute cannot be restricted (preceding part hour 
is either not restricted or by a non-EQ relation)
{quote}

 I know that there is already jira 
[CASSANDRA-4415|https://issues.apache.org/jira/browse/CASSANDRA-4415] which is 
a really  good idea and also 
[CASSANDRA-4851|https://issues.apache.org/jira/browse/CASSANDRA-4851] but the 
issue raised above is *beyond the scope of just paging data*.

 People are using more and more compound primary keys to model with Cassandra 
and they should be able to do slice queries with inequality from all compound 
components.

 There are lots of use cases where such usage is required.




--
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-5956) Allow filtering on more than 1 clustered components


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

DOAN DuyHai updated CASSANDRA-5956:
---

Priority: Minor  (was: Major)

 Allow filtering on more than 1 clustered components
 ---

 Key: CASSANDRA-5956
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5956
 Project: Cassandra
  Issue Type: Improvement
  Components: API, Core
Reporter: DOAN DuyHai
Priority: Minor

 Right now I am preparing some slides for a talk and tutorial on Cassandra to 
 convince people switching from Thrift to CQL3. However I am facing serious 
 issue because of the limitation of CQL3 not being able to allow inequality on 
 more than 1 clustered component at a time.
  My example is quite trivial. Let's consider a table to collect daily metrics
 {code:sql}
 CREATE TABLE daily_metrics
 (
   day int, // day in MMDD format
   hour int, 
   minute int,
   second int,
   metrics blob, 
   PRIMARY KEY (day, hour, minute, second)
 )
 {code}
  I should be able to grep all metrics from a range of date
   // select all metrics from 8:30am to 10am
  {code:sql}
  SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 8 AND 
 minute = 30 and hour = 10
  {code}
  // select all metrics of the day from 6:30pm
  {code:sql}
  SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 18 AND 
 minute = 30 
  {code}
  
  Right now it is just IMPOSSIBLE to do this kind of query with CQL3, which is 
 PITA. We always get the error message
 {quote}
 Bad Request: PRIMARY KEY part minute cannot be restricted (preceding part 
 hour is either not restricted or by a non-EQ relation)
 {quote}
  I know that there is already jira 
 [CASSANDRA-4415|https://issues.apache.org/jira/browse/CASSANDRA-4415] which 
 is a really  good idea and also 
 [CASSANDRA-4851|https://issues.apache.org/jira/browse/CASSANDRA-4851] but the 
 issue raised above is *beyond the scope of just paging data*.
  People are using more and more compound primary keys to model with Cassandra 
 and they should be able to do slice queries with inequality from all compound 
 components.
  There are lots of use cases where such usage is required.

--
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-5956) Allow filtering on more than 1 clustered components


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

DOAN DuyHai updated CASSANDRA-5956:
---

Description: 
Right now I am preparing some slides for a talk and tutorial on Cassandra to 
convince people switching from Thrift to CQL3. However I am facing issues 
because of the limitation of CQL3 not being able to allow inequality on more 
than 1 clustered component at a time.

 My example is quite trivial. Let's consider a table to collect daily metrics

{code:sql}
CREATE TABLE daily_metrics
(
  day int, // day in MMDD format
  hour int, 
  minute int,
  second int,
  metrics blob, 
  PRIMARY KEY (day, hour, minute, second)
)
{code}

 I should be able to grep all metrics from a range of date

  // select all metrics from 8:30am to 10am
 {code:sql}
 SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 8 AND 
minute = 30 and hour = 10
 {code}

 // select all metrics of the day from 6:30pm
 {code:sql}
 SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 18 AND 
minute = 30 
 {code}


 Right now it is just IMPOSSIBLE to do this kind of query with CQL3, which is 
PITA. We always get the error message

{quote}
Bad Request: PRIMARY KEY part minute cannot be restricted (preceding part hour 
is either not restricted or by a non-EQ relation)
{quote}

 Of course the example is trivial and I can just model the timestamp with 1 
component by sticking hour, minute and second together. However the limitation 
is still there and indeed there is no technical limitation to allow such a 
query, except from some effort in CQL3 parsing and validation.


 I know that there is already jira 
[CASSANDRA-4415|https://issues.apache.org/jira/browse/CASSANDRA-4415] which is 
a really  good idea and also 
[CASSANDRA-4851|https://issues.apache.org/jira/browse/CASSANDRA-4851] but the 
issue raised above is *beyond the scope of just paging data*.

 People are using more and more compound primary keys to model with Cassandra 
and they should be able to do slice queries with inequality from all compound 
components.

  was:
Right now I am preparing some slides for a talk and tutorial on Cassandra to 
convince people switching from Thrift to CQL3. However I am facing serious 
issue because of the limitation of CQL3 not being able to allow inequality on 
more than 1 clustered component at a time.

 My example is quite trivial. Let's consider a table to collect daily metrics

{code:sql}
CREATE TABLE daily_metrics
(
  day int, // day in MMDD format
  hour int, 
  minute int,
  second int,
  metrics blob, 
  PRIMARY KEY (day, hour, minute, second)
)
{code}

 I should be able to grep all metrics from a range of date

  // select all metrics from 8:30am to 10am
 {code:sql}
 SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 8 AND 
minute = 30 and hour = 10
 {code}

 // select all metrics of the day from 6:30pm
 {code:sql}
 SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 18 AND 
minute = 30 
 {code}

 
 Right now it is just IMPOSSIBLE to do this kind of query with CQL3, which is 
PITA. We always get the error message

{quote}
Bad Request: PRIMARY KEY part minute cannot be restricted (preceding part hour 
is either not restricted or by a non-EQ relation)
{quote}

 I know that there is already jira 
[CASSANDRA-4415|https://issues.apache.org/jira/browse/CASSANDRA-4415] which is 
a really  good idea and also 
[CASSANDRA-4851|https://issues.apache.org/jira/browse/CASSANDRA-4851] but the 
issue raised above is *beyond the scope of just paging data*.

 People are using more and more compound primary keys to model with Cassandra 
and they should be able to do slice queries with inequality from all compound 
components.

 There are lots of use cases where such usage is required.





 Allow filtering on more than 1 clustered components
 ---

 Key: CASSANDRA-5956
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5956
 Project: Cassandra
  Issue Type: Improvement
  Components: API, Core
Reporter: DOAN DuyHai
Priority: Minor

 Right now I am preparing some slides for a talk and tutorial on Cassandra to 
 convince people switching from Thrift to CQL3. However I am facing issues 
 because of the limitation of CQL3 not being able to allow inequality on more 
 than 1 clustered component at a time.
  My example is quite trivial. Let's consider a table to collect daily metrics
 {code:sql}
 CREATE TABLE daily_metrics
 (
   day int, // day in MMDD format
   hour int, 
   minute int,
   second int,
   metrics blob, 
   PRIMARY KEY (day, hour, minute, second)
 )
 {code}
  I should be able to grep all metrics from a range of date
   // select all metrics from 8:30am to 10am
  {code:sql}
  SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour

[jira] [Updated] (CASSANDRA-5956) Allow filtering on more than 1 clustered component in CQL3


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

DOAN DuyHai updated CASSANDRA-5956:
---

Summary: Allow filtering on more than 1 clustered component in CQL3  (was: 
Allow filtering on more than 1 clustered components)

 Allow filtering on more than 1 clustered component in CQL3
 --

 Key: CASSANDRA-5956
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5956
 Project: Cassandra
  Issue Type: Improvement
  Components: API, Core
Reporter: DOAN DuyHai
Priority: Minor

 Right now I am preparing some slides for a talk and tutorial on Cassandra to 
 convince people switching from Thrift to CQL3. However I am facing issues 
 because of the limitation of CQL3 not being able to allow inequality on more 
 than 1 clustered component at a time.
  My example is quite trivial. Let's consider a table to collect daily metrics
 {code:sql}
 CREATE TABLE daily_metrics
 (
   day int, // day in MMDD format
   hour int, 
   minute int,
   second int,
   metrics blob, 
   PRIMARY KEY (day, hour, minute, second)
 )
 {code}
  I should be able to grep all metrics from a range of date
   // select all metrics from 8:30am to 10am
  {code:sql}
  SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 8 AND 
 minute = 30 and hour = 10
  {code}
  // select all metrics of the day from 6:30pm
  {code:sql}
  SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 18 AND 
 minute = 30 
  {code}
  Right now it is just IMPOSSIBLE to do this kind of query with CQL3, which is 
 PITA. We always get the error message
 {quote}
 Bad Request: PRIMARY KEY part minute cannot be restricted (preceding part 
 hour is either not restricted or by a non-EQ relation)
 {quote}
  Of course the example is trivial and I can just model the timestamp with 1 
 component by sticking hour, minute and second together. However the 
 limitation is still there and indeed there is no technical limitation to 
 allow such a query, except from some effort in CQL3 parsing and validation.
  I know that there is already jira 
 [CASSANDRA-4415|https://issues.apache.org/jira/browse/CASSANDRA-4415] which 
 is a really  good idea and also 
 [CASSANDRA-4851|https://issues.apache.org/jira/browse/CASSANDRA-4851] but the 
 issue raised above is *beyond the scope of just paging data*.
  People are using more and more compound primary keys to model with Cassandra 
 and they should be able to do slice queries with inequality from all compound 
 components.

--
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-5953) Replication validation is broken

2013-08-30 Thread Jeremiah Jordan (JIRA)


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

Jeremiah Jordan updated CASSANDRA-5953:
---

Description: 
On my local, single node cluster, RF=3 inserts should not succeed:

{noformat}
cqlsh CREATE KEYSPACE mykeyspace WITH REPLICATION = { 'class' : 
'SimpleStrategy', 'replication_factor' : 3 };
cqlsh use mykeyspace ;
cqlsh:mykeyspace CREATE TABLE users (
  ...   user_id int PRIMARY KEY, 
  ...   fname text, 
  ...   lname text
  ... );
cqlsh:mykeyspace INSERT INTO users (user_id,  fname, lname) 
  ...   VALUES (1745, 'john', 'smith');
cqlsh:mykeyspace select * from users;

 user_id | fname | lname
-+---+---
1745 |  john | smith
{noformat}


  was:
On my local, single node cluster, RF=3 inserts should not succeed:

{quote}
cqlsh CREATE KEYSPACE mykeyspace WITH REPLICATION = { 'class' : 
'SimpleStrategy', 'replication_factor' : 3 };
cqlsh use mykeyspace ;
cqlsh:mykeyspace CREATE TABLE users (
  ...   user_id int PRIMARY KEY, 
  ...   fname text, 
  ...   lname text
  ... );
cqlsh:mykeyspace INSERT INTO users (user_id,  fname, lname) 
  ...   VALUES (1745, 'john', 'smith');
cqlsh:mykeyspace select * from users;

 user_id | fname | lname
-+---+---
1745 |  john | smith
{quote}



 Replication validation is broken
 

 Key: CASSANDRA-5953
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5953
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 1.2.10


 On my local, single node cluster, RF=3 inserts should not succeed:
 {noformat}
 cqlsh CREATE KEYSPACE mykeyspace WITH REPLICATION = { 'class' : 
 'SimpleStrategy', 'replication_factor' : 3 };
 cqlsh use mykeyspace ;
 cqlsh:mykeyspace CREATE TABLE users (
   ...   user_id int PRIMARY KEY, 
   ...   fname text, 
   ...   lname text
   ... );
 cqlsh:mykeyspace INSERT INTO users (user_id,  fname, lname) 
   ...   VALUES (1745, 'john', 'smith');
 cqlsh:mykeyspace select * from users;
  user_id | fname | lname
 -+---+---
 1745 |  john | smith
 {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-5954) Make nodetool ring print an error message and suggest nodetool status when vnodes are enabled

2013-08-30 Thread Jeremiah Jordan (JIRA)


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

Jeremiah Jordan commented on CASSANDRA-5954:


I agree, put a message at the bottom of the output which says Now that you 
watched 5000 tokens scroll by, you probably want nodetool status.

 Make nodetool ring print an error message and suggest nodetool status when 
 vnodes are enabled
 -

 Key: CASSANDRA-5954
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5954
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jonathan Ellis
Assignee: Lyuben Todorov
Priority: Minor
 Fix For: 2.0.1




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

[Cassandra Wiki] Trivial Update of GettingStarted by JonathanEllis

2013-08-30 Thread Apache Wiki

Dear Wiki user,

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

The GettingStarted page has been changed by JonathanEllis:
https://wiki.apache.org/cassandra/GettingStarted?action=diffrev1=92rev2=93

  
  In addition to seeds, you'll also need to configure the IP interface to 
listen on for Gossip and CQL, ('''listen_address''' and '''rpc_address''' 
respectively). Use a 'listen_address` that will be reachable from the 
`listen_address` used on all other nodes, and a `rpc_address` that will be 
accessible to clients.
  
- Once everything is configured and the nodes are running, use the 
`bin/nodetool ring` utility to verify a properly connected cluster. For example:
+ Once everything is configured and the nodes are running, use the 
`bin/nodetool status` utility to verify a properly connected cluster. For 
example:
  
  {{{
  eevans@achilles:‾$ bin/nodetool -host 192.168.0.10 -p 7199 status

[jira] [Resolved] (CASSANDRA-5956) Allow filtering on more than 1 clustered component in CQL3

2013-08-30 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne resolved CASSANDRA-5956.
-

Resolution: Duplicate

bq. also CASSANDRA-4851 but the issue raised above is beyond the scope of just 
paging data

Well it's not. Let's not play too much on words, the description of 
CASSANDRA-4851 is pretty clear that that the goal is to allow slicing over 
composites (and that paging is just one motivation). But if that wasn't 
clear, let me confirm that this is what CASSANDRA-4851 will be about so there 
is no reason to have 2 tickets. So closing that one as duplicate.

bq. My example is quite trivial.

As a side note, while the example is trivial in its complexity, I can't really 
see any benefit in splitting a time into 3 columns like done here, rather than 
having a single timestamp column (even if CASSANDRA-4851 was implemented).  A 
single timestamp column would offer a greater precision yet with a smaller 
storage space. It also makes queries a bit easier to read imo and make it 
easier to work with in general client side (because drivers know it's a time).

So while I'd agree it's very easy to come up with toy examples where the 
absence of slicing over composites sounds very limiting, it is my experience 
that tables with multiple clustering columns are not *that* common in real 
models, and even when muliple clustering columns are useful, being able to 
slice in the same query over more than one of those columns is far from always 
needed. Anyway, just my 2 cents, I agree that this should be fixed ultimately, 
that's why I crated CASSANDRA-4851 in the first place.

{quote}
// select all metrics of the day from 6:30pm
{noformat}
SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 18 AND 
minute = 30
{noformat}
{quote}

I'll note that this query does *not* do what the comment above it pretends it 
does (it doesn't in SQL, and it would very arguably be a bug if it was in CQL). 
 That query selects all row of day 20130828 that have *both* their hour 
component after 18 *and* their minute component after 30. So it does *not* 
select 7:01pm for instance (which is why I'm strongly leaning towards adding 
the tuple-like syntax in CASSANDRA-4851).


 Allow filtering on more than 1 clustered component in CQL3
 --

 Key: CASSANDRA-5956
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5956
 Project: Cassandra
  Issue Type: Improvement
  Components: API, Core
Reporter: DOAN DuyHai
Priority: Minor

 Right now I am preparing some slides for a talk and tutorial on Cassandra to 
 convince people switching from Thrift to CQL3. However I am facing issues 
 because of the limitation of CQL3 not being able to allow inequality on more 
 than 1 clustered component at a time.
  My example is quite trivial. Let's consider a table to collect daily metrics
 {code:sql}
 CREATE TABLE daily_metrics
 (
   day int, // day in MMDD format
   hour int, 
   minute int,
   second int,
   metrics blob, 
   PRIMARY KEY (day, hour, minute, second)
 )
 {code}
  I should be able to grep all metrics from a range of date
   // select all metrics from 8:30am to 10am
  {code:sql}
  SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 8 AND 
 minute = 30 and hour = 10
  {code}
  // select all metrics of the day from 6:30pm
  {code:sql}
  SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour = 18 AND 
 minute = 30 
  {code}
  Right now it is just IMPOSSIBLE to do this kind of query with CQL3, which is 
 PITA. We always get the error message
 {quote}
 Bad Request: PRIMARY KEY part minute cannot be restricted (preceding part 
 hour is either not restricted or by a non-EQ relation)
 {quote}
  Of course the example is trivial and I can just model the timestamp with 1 
 component by sticking hour, minute and second together. However the 
 limitation is still there and indeed there is no technical limitation to 
 allow such a query, except from some effort in CQL3 parsing and validation.
  I know that there is already jira 
 [CASSANDRA-4415|https://issues.apache.org/jira/browse/CASSANDRA-4415] which 
 is a really  good idea and also 
 [CASSANDRA-4851|https://issues.apache.org/jira/browse/CASSANDRA-4851] but the 
 issue raised above is *beyond the scope of just paging data*.
  People are using more and more compound primary keys to model with Cassandra 
 and they should be able to do slice queries with inequality from all compound 
 components.

--
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-5939) Cache Providers calculate very different row sizes

2013-08-30 Thread Chris Burroughs (JIRA)


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

Chris Burroughs commented on CASSANDRA-5939:


Enable ROWS_ONLY caching on Standard1 from, wrote data, restarted and read data 
until row cache was full.  Used 1024 MB ConcurrentLinkedHashCacheProvider.

 * entries: 12,386
 * RowCacheSize: 1,073,680,880

Stop reading, run gc through jconsole.  RowCacheSize remains 1,073,680,880 but 
total heap used is 108,779,240.  From a heap dump yourkit estimated the 
retained size of the ConcurrentLinkedHashCache at 37,481,616, but I'm not sure 
how relevant that calculation is.  I'm not sure what the correct value, is but 
the estimated row cache size can't possible be correct since it is far larger 
than total used heap.

 Cache Providers calculate very different row sizes
 --

 Key: CASSANDRA-5939
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5939
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: 1.2.8
Reporter: Chris Burroughs
Assignee: Vijay

 Took the same production node and bounced it 4 times comparing version and 
 cache provider.  ConcurrentLinkedHashCacheProvider and 
 SerializingCacheProvider produce very different results resulting in an order 
 of magnitude difference in rows cached.  In all cases the row cache size was 
 2048 MB.  Hit rate is provided for color, but entries  size are the 
 important part.
 1.2.8 ConcurrentLinkedHashCacheProvider:
  * entries: 23,217
  * hit rate: 43%
  * size: 2,147,398,344
 1.2.8 about 20 minutes of SerializingCacheProvider:
  * entries: 221,709
  * hit rate: 68%
  * size: 18,417254
 1.2.5 ConcurrentLinkedHashCacheProvider:
  * entries: 25,967
  * hit rate: ~ 50%
  * size:  2,147,421,704
 1.2.5 about 20 minutes of SerializingCacheProvider:
  * entries: 228,457
  * hit rate: ~ 70%
  * size: 19,070,315
 A related(?) problem is that the ConcurrentLinkedHashCacheProvider sizes seem 
 to be highly variable.  Digging up the values for 5 different nodes in the 
 cluster using ConcurrentLinkedHashCacheProvider shows a wide variance in 
 number of entries:
  * 12k
  * 444k
  * 10k
  * 25k
  * 25k

--
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-5957) Cannot drop keyspace Keyspace1 after running cassandra-stress

2013-08-30 Thread JIRA

Piotr Kołaczkowski created CASSANDRA-5957:
-

 Summary: Cannot drop keyspace Keyspace1 after running 
cassandra-stress
 Key: CASSANDRA-5957
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5957
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Cassandra 1.2.9 freshly built from cassandra-1.2 branch 
(f5b224cf9aa0f319d51078ef4b78d55e36613963)
Reporter: Piotr Kołaczkowski


Steps to reproduce:
# Set MAX_HEAP=2G, HEAP_NEWSIZE=400M
# Run ./cassandra-stress -n 5 -c 400 -S 256
# The test should complete despite several warnings about low heap memory.
# Try to drop keyspace:
{noformat}
cqlsh drop keyspace Keyspace1;
TSocket read 0 bytes
{noformat}

system.log:
{noformat}
 INFO 15:10:46,516 Enqueuing flush of 
Memtable-schema_columnfamilies@2127258371(0/0 serialized/live bytes, 1 ops)
 INFO 15:10:46,516 Writing Memtable-schema_columnfamilies@2127258371(0/0 
serialized/live bytes, 1 ops)
 INFO 15:10:46,690 Completed flushing 
/var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ic-6-Data.db
 (38 bytes) for commitlog position ReplayPosition(segmentId=1377867520699, 
position=19794574)
 INFO 15:10:46,692 Enqueuing flush of Memtable-schema_columns@1997964959(0/0 
serialized/live bytes, 1 ops)
 INFO 15:10:46,693 Writing Memtable-schema_columns@1997964959(0/0 
serialized/live bytes, 1 ops)
 INFO 15:10:46,857 Completed flushing 
/var/lib/cassandra/data/system/schema_columns/system-schema_columns-ic-6-Data.db
 (38 bytes) for commitlog position ReplayPosition(segmentId=1377867520699, 
position=19794574)
 INFO 15:10:46,897 Enqueuing flush of Memtable-local@1366216652(98/98 
serialized/live bytes, 3 ops)
 INFO 15:10:46,898 Writing Memtable-local@1366216652(98/98 serialized/live 
bytes, 3 ops)
 INFO 15:10:47,064 Completed flushing 
/var/lib/cassandra/data/system/local/system-local-ic-12-Data.db (139 bytes) for 
commitlog position ReplayPosition(segmentId=1377867520699, position=19794845)
 INFO 15:10:48,956 Enqueuing flush of Memtable-local@432522279(46/46 
serialized/live bytes, 1 ops)
 INFO 15:10:48,957 Writing Memtable-local@432522279(46/46 serialized/live 
bytes, 1 ops)
 INFO 15:10:49,132 Compaction interrupted: 
Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
400882073/1094043713)bytes
 INFO 15:10:49,175 Compaction interrupted: 
Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
147514075/645675954)bytes
 INFO 15:10:49,185 Compaction interrupted: 
Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
223249644/609072261)bytes
 INFO 15:10:49,202 Compaction interrupted: 
Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
346471085/990388210)bytes
 INFO 15:10:49,215 Compaction interrupted: 
Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
294748503/2092376617)bytes
 INFO 15:10:49,257 Compaction interrupted: 
Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
692722235/739328646)bytes
 INFO 15:10:49,285 Completed flushing 
/var/lib/cassandra/data/system/local/system-local-ic-13-Data.db (82 bytes) for 
commitlog position ReplayPosition(segmentId=1377867520699, position=19794974)
 INFO 15:10:49,286 Compacting 
[SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-10-Data.db'),
 
SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-13-Data.db'),
 
SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-12-Data.db'),
 
SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-11-Data.db')]
ERROR 15:10:49,287 Error occurred during processing of message.
java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
java.lang.AssertionError: 
SSTableReader(path='/var/lib/cassandra/data/Keyspace1/Standard1/Keyspace1-Standard1-ic-78-Data.db')
 was already marked compacted
at 
org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:378)
at 
org.apache.cassandra.service.MigrationManager.announce(MigrationManager.java:281)
at 
org.apache.cassandra.service.MigrationManager.announceKeyspaceDrop(MigrationManager.java:262)
at 
org.apache.cassandra.cql.QueryProcessor.processStatement(QueryProcessor.java:718)
at 
org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:775)
at 
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1668)
at 
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:4048)
at 
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:4036)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at

[jira] [Commented] (CASSANDRA-5957) Cannot drop keyspace Keyspace1 after running cassandra-stress

2013-08-30 Thread Andy Cobley (JIRA)


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

Andy Cobley commented on CASSANDRA-5957:


IS this because stress test is creating the keyspace via thrift rather than CQL 
?  try running the test with the --enable-cql option and then droping the 
keyspace ?


 Cannot drop keyspace Keyspace1 after running cassandra-stress
 -

 Key: CASSANDRA-5957
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5957
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Cassandra 1.2.9 freshly built from cassandra-1.2 branch 
 (f5b224cf9aa0f319d51078ef4b78d55e36613963)
Reporter: Piotr Kołaczkowski

 Steps to reproduce:
 # Set MAX_HEAP=2G, HEAP_NEWSIZE=400M
 # Run ./cassandra-stress -n 5 -c 400 -S 256
 # The test should complete despite several warnings about low heap memory.
 # Try to drop keyspace:
 {noformat}
 cqlsh drop keyspace Keyspace1;
 TSocket read 0 bytes
 {noformat}
 system.log:
 {noformat}
  INFO 15:10:46,516 Enqueuing flush of 
 Memtable-schema_columnfamilies@2127258371(0/0 serialized/live bytes, 1 ops)
  INFO 15:10:46,516 Writing Memtable-schema_columnfamilies@2127258371(0/0 
 serialized/live bytes, 1 ops)
  INFO 15:10:46,690 Completed flushing 
 /var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ic-6-Data.db
  (38 bytes) for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794574)
  INFO 15:10:46,692 Enqueuing flush of Memtable-schema_columns@1997964959(0/0 
 serialized/live bytes, 1 ops)
  INFO 15:10:46,693 Writing Memtable-schema_columns@1997964959(0/0 
 serialized/live bytes, 1 ops)
  INFO 15:10:46,857 Completed flushing 
 /var/lib/cassandra/data/system/schema_columns/system-schema_columns-ic-6-Data.db
  (38 bytes) for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794574)
  INFO 15:10:46,897 Enqueuing flush of Memtable-local@1366216652(98/98 
 serialized/live bytes, 3 ops)
  INFO 15:10:46,898 Writing Memtable-local@1366216652(98/98 serialized/live 
 bytes, 3 ops)
  INFO 15:10:47,064 Completed flushing 
 /var/lib/cassandra/data/system/local/system-local-ic-12-Data.db (139 bytes) 
 for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794845)
  INFO 15:10:48,956 Enqueuing flush of Memtable-local@432522279(46/46 
 serialized/live bytes, 1 ops)
  INFO 15:10:48,957 Writing Memtable-local@432522279(46/46 serialized/live 
 bytes, 1 ops)
  INFO 15:10:49,132 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 400882073/1094043713)bytes
  INFO 15:10:49,175 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 147514075/645675954)bytes
  INFO 15:10:49,185 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 223249644/609072261)bytes
  INFO 15:10:49,202 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 346471085/990388210)bytes
  INFO 15:10:49,215 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 294748503/2092376617)bytes
  INFO 15:10:49,257 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 692722235/739328646)bytes
  INFO 15:10:49,285 Completed flushing 
 /var/lib/cassandra/data/system/local/system-local-ic-13-Data.db (82 bytes) 
 for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794974)
  INFO 15:10:49,286 Compacting 
 [SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-10-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-13-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-12-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-11-Data.db')]
 ERROR 15:10:49,287 Error occurred during processing of message.
 java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
 java.lang.AssertionError: 
 SSTableReader(path='/var/lib/cassandra/data/Keyspace1/Standard1/Keyspace1-Standard1-ic-78-Data.db')
  was already marked compacted
   at 
 org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:378)
   at 
 org.apache.cassandra.service.MigrationManager.announce(MigrationManager.java:281)
   at 
 org.apache.cassandra.service.MigrationManager.announceKeyspaceDrop(MigrationManager.java:262)
   at 
 org.apache.cassandra.cql.QueryProcessor.processStatement(QueryProcessor.java:718)
   at 
 org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:775)
   at

[jira] [Updated] (CASSANDRA-5957) Cannot drop keyspace Keyspace1 after running cassandra-stress


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

Jonathan Ellis updated CASSANDRA-5957:
--

 Reviewer: jbellis
 Priority: Minor  (was: Major)
Fix Version/s: 1.2.10
 Assignee: Aleksey Yeschenko

 Cannot drop keyspace Keyspace1 after running cassandra-stress
 -

 Key: CASSANDRA-5957
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5957
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Cassandra 1.2.9 freshly built from cassandra-1.2 branch 
 (f5b224cf9aa0f319d51078ef4b78d55e36613963)
Reporter: Piotr Kołaczkowski
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 1.2.10


 Steps to reproduce:
 # Set MAX_HEAP=2G, HEAP_NEWSIZE=400M
 # Run ./cassandra-stress -n 5 -c 400 -S 256
 # The test should complete despite several warnings about low heap memory.
 # Try to drop keyspace:
 {noformat}
 cqlsh drop keyspace Keyspace1;
 TSocket read 0 bytes
 {noformat}
 system.log:
 {noformat}
  INFO 15:10:46,516 Enqueuing flush of 
 Memtable-schema_columnfamilies@2127258371(0/0 serialized/live bytes, 1 ops)
  INFO 15:10:46,516 Writing Memtable-schema_columnfamilies@2127258371(0/0 
 serialized/live bytes, 1 ops)
  INFO 15:10:46,690 Completed flushing 
 /var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ic-6-Data.db
  (38 bytes) for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794574)
  INFO 15:10:46,692 Enqueuing flush of Memtable-schema_columns@1997964959(0/0 
 serialized/live bytes, 1 ops)
  INFO 15:10:46,693 Writing Memtable-schema_columns@1997964959(0/0 
 serialized/live bytes, 1 ops)
  INFO 15:10:46,857 Completed flushing 
 /var/lib/cassandra/data/system/schema_columns/system-schema_columns-ic-6-Data.db
  (38 bytes) for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794574)
  INFO 15:10:46,897 Enqueuing flush of Memtable-local@1366216652(98/98 
 serialized/live bytes, 3 ops)
  INFO 15:10:46,898 Writing Memtable-local@1366216652(98/98 serialized/live 
 bytes, 3 ops)
  INFO 15:10:47,064 Completed flushing 
 /var/lib/cassandra/data/system/local/system-local-ic-12-Data.db (139 bytes) 
 for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794845)
  INFO 15:10:48,956 Enqueuing flush of Memtable-local@432522279(46/46 
 serialized/live bytes, 1 ops)
  INFO 15:10:48,957 Writing Memtable-local@432522279(46/46 serialized/live 
 bytes, 1 ops)
  INFO 15:10:49,132 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 400882073/1094043713)bytes
  INFO 15:10:49,175 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 147514075/645675954)bytes
  INFO 15:10:49,185 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 223249644/609072261)bytes
  INFO 15:10:49,202 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 346471085/990388210)bytes
  INFO 15:10:49,215 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 294748503/2092376617)bytes
  INFO 15:10:49,257 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 692722235/739328646)bytes
  INFO 15:10:49,285 Completed flushing 
 /var/lib/cassandra/data/system/local/system-local-ic-13-Data.db (82 bytes) 
 for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794974)
  INFO 15:10:49,286 Compacting 
 [SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-10-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-13-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-12-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-11-Data.db')]
 ERROR 15:10:49,287 Error occurred during processing of message.
 java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
 java.lang.AssertionError: 
 SSTableReader(path='/var/lib/cassandra/data/Keyspace1/Standard1/Keyspace1-Standard1-ic-78-Data.db')
  was already marked compacted
   at 
 org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:378)
   at 
 org.apache.cassandra.service.MigrationManager.announce(MigrationManager.java:281)
   at 
 org.apache.cassandra.service.MigrationManager.announceKeyspaceDrop(MigrationManager.java:262)
   at 
 org.apache.cassandra.cql.QueryProcessor.processStatement(QueryProcessor.java:718)
   at 
 org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:775)
   at

[jira] [Commented] (CASSANDRA-5939) Cache Providers calculate very different row sizes


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

Jonathan Ellis commented on CASSANDRA-5939:
---

bq. we have removed CLHM in 2.0

Yup.  The cost/benefit of spending time on CLHM just isn't there for me.  
Especially as the guy who argued we should remove row cache entirely. :)

Unless you are planning to dig in, Chris, I propose we wontfix.

 Cache Providers calculate very different row sizes
 --

 Key: CASSANDRA-5939
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5939
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: 1.2.8
Reporter: Chris Burroughs
Assignee: Vijay

 Took the same production node and bounced it 4 times comparing version and 
 cache provider.  ConcurrentLinkedHashCacheProvider and 
 SerializingCacheProvider produce very different results resulting in an order 
 of magnitude difference in rows cached.  In all cases the row cache size was 
 2048 MB.  Hit rate is provided for color, but entries  size are the 
 important part.
 1.2.8 ConcurrentLinkedHashCacheProvider:
  * entries: 23,217
  * hit rate: 43%
  * size: 2,147,398,344
 1.2.8 about 20 minutes of SerializingCacheProvider:
  * entries: 221,709
  * hit rate: 68%
  * size: 18,417254
 1.2.5 ConcurrentLinkedHashCacheProvider:
  * entries: 25,967
  * hit rate: ~ 50%
  * size:  2,147,421,704
 1.2.5 about 20 minutes of SerializingCacheProvider:
  * entries: 228,457
  * hit rate: ~ 70%
  * size: 19,070,315
 A related(?) problem is that the ConcurrentLinkedHashCacheProvider sizes seem 
 to be highly variable.  Digging up the values for 5 different nodes in the 
 cluster using ConcurrentLinkedHashCacheProvider shows a wide variance in 
 number of entries:
  * 12k
  * 444k
  * 10k
  * 25k
  * 25k

--
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-5958) Unable to find property errors from snakeyaml are confusing

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

J.B. Langston updated CASSANDRA-5958:
-

Description:
When an unexpected property is present in cassandra.yaml (e.g. after
upgrading), snakeyaml outputs the following message:

{code}Unable to find property 'some_property' on class:
org.apache.cassandra.config.Config{code}

The error message is kind of counterintuitive because at first glance it seems
to suggest the property is missing from the yaml file, when in fact the error
is caused by the *presence* of an unrecognized property. I know if you read it
carefully it says it can't find the property on the class, but this has
confused more than one user.

I think we should catch this exception and wrap it in another exception that
says something like this:

{code}Please remove 'some_property' from your cassandra.yaml. It is not
recognized by this version of Cassandra.{code}

was:
When an unexpected property is present in cassandra.yaml (e.g. after
upgrading), snakeyaml outputs the following message:

Unable to find property 'some_property' on class:
org.apache.cassandra.config.Config

I think we catch this exception and wrap it in another exception that says
something like this:

Please remove 'some_property' from your cassandra.yaml. It is not recognized by
this version of Cassandra.

Unable to find property errors from snakeyaml are confusing
-

Key: CASSANDRA-5958
URL: https://issues.apache.org/jira/browse/CASSANDRA-5958
Project: Cassandra
Issue Type: Bug
Reporter: J.B. Langston
Priority: Minor

When an unexpected property is present in cassandra.yaml (e.g. after
upgrading), snakeyaml outputs the following message:
{code}Unable to find property 'some_property' on class:
org.apache.cassandra.config.Config{code}
The error message is kind of counterintuitive because at first glance it
seems to suggest the property is missing from the yaml file, when in fact the
error is caused by the *presence* of an unrecognized property. I know if you
read it carefully it says it can't find the property on the class, but this
has confused more than one user.
I think we should catch this exception and wrap it in another exception that
says something like this:
{code}Please remove 'some_property' from your cassandra.yaml. It is not
recognized by this version of Cassandra.{code}

[jira] [Commented] (CASSANDRA-5955) The native protocol server can trigger a Netty bug


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

Jonathan Ellis commented on CASSANDRA-5955:
---

+1 on principle

 The native protocol server can trigger a Netty bug
 --

 Key: CASSANDRA-5955
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5955
 Project: Cassandra
  Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
 Fix For: 1.2.10


 The patch from CASSANDRA-5926 did fix the original deadlock, but 
 unfortunately we can now run into a netty bug (with 
 MemoryAwareThreadPoolExecutor): https://github.com/netty/netty/issues/1310.
 That bug has been fixed in netty 3.6.6 but we're currently using an older 
 version (3.5.9). So we should just upgrade our dependency to 3.6.6. 

--
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-5958) Unable to find property errors from snakeyaml are confusing

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

J.B. Langston updated CASSANDRA-5958:
-

Description:
When an unexpected property is present in cassandra.yaml (e.g. after
upgrading), snakeyaml outputs the following message:

{code}Unable to find property 'some_property' on class:
org.apache.cassandra.config.Config{code}

I think we should catch this exception and wrap it in another exception that
says something like this:

{code}Please remove 'some_property' from your cassandra.yaml. It is not
recognized by this version of Cassandra.{code}

Also, it might make sense to make this a warning instead of a fatal error, and
just ignore the unwanted property.

was:
When an unexpected property is present in cassandra.yaml (e.g. after
upgrading), snakeyaml outputs the following message:

{code}Unable to find property 'some_property' on class:
org.apache.cassandra.config.Config{code}

I think we should catch this exception and wrap it in another exception that
says something like this:

{code}Please remove 'some_property' from your cassandra.yaml. It is not
recognized by this version of Cassandra.{code}

Unable to find property errors from snakeyaml are confusing
-

Key: CASSANDRA-5958
URL: https://issues.apache.org/jira/browse/CASSANDRA-5958
Project: Cassandra
Issue Type: Bug
Reporter: J.B. Langston
Priority: Minor

[jira] [Commented] (CASSANDRA-5958) Unable to find property errors from snakeyaml are confusing

2013-08-30 Thread Chris Burroughs (JIRA)

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

Chris Burroughs commented on CASSANDRA-5958:

Which version is this with? We upgraded snakyaml in 2.0.x and it might have
improved error messages.

Unable to find property errors from snakeyaml are confusing
-

Key: CASSANDRA-5958
URL: https://issues.apache.org/jira/browse/CASSANDRA-5958
Project: Cassandra
Issue Type: Bug
Reporter: J.B. Langston
Priority: Minor

[jira] [Commented] (CASSANDRA-5958) Unable to find property errors from snakeyaml are confusing

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

J.B. Langston commented on CASSANDRA-5958:
--

1.2 and prior

Unable to find property errors from snakeyaml are confusing
-

Key: CASSANDRA-5958
URL: https://issues.apache.org/jira/browse/CASSANDRA-5958
Project: Cassandra
Issue Type: Bug
Reporter: J.B. Langston
Priority: Minor

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


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

Greg DeAngelis commented on CASSANDRA-4757:
---

Sorry that was an oversight by me. I will fix that today.

 Expose bulk loading progress/status over jmx
 

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

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


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

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

[jira] [Commented] (CASSANDRA-5957) Cannot drop keyspace Keyspace1 after running cassandra-stress

2013-08-30 Thread Andy Cobley (JIRA)


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

Andy Cobley commented on CASSANDRA-5957:


Did you try deleting the keyspace with cassandra-cli  before running the test 
with --enable-cql ?


 Cannot drop keyspace Keyspace1 after running cassandra-stress
 -

 Key: CASSANDRA-5957
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5957
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Cassandra 1.2.9 freshly built from cassandra-1.2 branch 
 (f5b224cf9aa0f319d51078ef4b78d55e36613963)
Reporter: Piotr Kołaczkowski
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 1.2.10


 Steps to reproduce:
 # Set MAX_HEAP=2G, HEAP_NEWSIZE=400M
 # Run ./cassandra-stress -n 5 -c 400 -S 256
 # The test should complete despite several warnings about low heap memory.
 # Try to drop keyspace:
 {noformat}
 cqlsh drop keyspace Keyspace1;
 TSocket read 0 bytes
 {noformat}
 system.log:
 {noformat}
  INFO 15:10:46,516 Enqueuing flush of 
 Memtable-schema_columnfamilies@2127258371(0/0 serialized/live bytes, 1 ops)
  INFO 15:10:46,516 Writing Memtable-schema_columnfamilies@2127258371(0/0 
 serialized/live bytes, 1 ops)
  INFO 15:10:46,690 Completed flushing 
 /var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ic-6-Data.db
  (38 bytes) for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794574)
  INFO 15:10:46,692 Enqueuing flush of Memtable-schema_columns@1997964959(0/0 
 serialized/live bytes, 1 ops)
  INFO 15:10:46,693 Writing Memtable-schema_columns@1997964959(0/0 
 serialized/live bytes, 1 ops)
  INFO 15:10:46,857 Completed flushing 
 /var/lib/cassandra/data/system/schema_columns/system-schema_columns-ic-6-Data.db
  (38 bytes) for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794574)
  INFO 15:10:46,897 Enqueuing flush of Memtable-local@1366216652(98/98 
 serialized/live bytes, 3 ops)
  INFO 15:10:46,898 Writing Memtable-local@1366216652(98/98 serialized/live 
 bytes, 3 ops)
  INFO 15:10:47,064 Completed flushing 
 /var/lib/cassandra/data/system/local/system-local-ic-12-Data.db (139 bytes) 
 for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794845)
  INFO 15:10:48,956 Enqueuing flush of Memtable-local@432522279(46/46 
 serialized/live bytes, 1 ops)
  INFO 15:10:48,957 Writing Memtable-local@432522279(46/46 serialized/live 
 bytes, 1 ops)
  INFO 15:10:49,132 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 400882073/1094043713)bytes
  INFO 15:10:49,175 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 147514075/645675954)bytes
  INFO 15:10:49,185 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 223249644/609072261)bytes
  INFO 15:10:49,202 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 346471085/990388210)bytes
  INFO 15:10:49,215 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 294748503/2092376617)bytes
  INFO 15:10:49,257 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 692722235/739328646)bytes
  INFO 15:10:49,285 Completed flushing 
 /var/lib/cassandra/data/system/local/system-local-ic-13-Data.db (82 bytes) 
 for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794974)
  INFO 15:10:49,286 Compacting 
 [SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-10-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-13-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-12-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-11-Data.db')]
 ERROR 15:10:49,287 Error occurred during processing of message.
 java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
 java.lang.AssertionError: 
 SSTableReader(path='/var/lib/cassandra/data/Keyspace1/Standard1/Keyspace1-Standard1-ic-78-Data.db')
  was already marked compacted
   at 
 org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:378)
   at 
 org.apache.cassandra.service.MigrationManager.announce(MigrationManager.java:281)
   at 
 org.apache.cassandra.service.MigrationManager.announceKeyspaceDrop(MigrationManager.java:262)
   at 
 org.apache.cassandra.cql.QueryProcessor.processStatement(QueryProcessor.java:718)
   at 
 org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:775)
   at

[jira] [Commented] (CASSANDRA-5957) Cannot drop keyspace Keyspace1 after running cassandra-stress

2013-08-30 Thread JIRA


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

Piotr Kołaczkowski commented on CASSANDRA-5957:
---

No. I checked with --enable-cql (after starting from fresh empty 
/var/lib/cassandra) and the problem still persists.

 Cannot drop keyspace Keyspace1 after running cassandra-stress
 -

 Key: CASSANDRA-5957
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5957
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Cassandra 1.2.9 freshly built from cassandra-1.2 branch 
 (f5b224cf9aa0f319d51078ef4b78d55e36613963)
Reporter: Piotr Kołaczkowski
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 1.2.10


 Steps to reproduce:
 # Set MAX_HEAP=2G, HEAP_NEWSIZE=400M
 # Run ./cassandra-stress -n 5 -c 400 -S 256
 # The test should complete despite several warnings about low heap memory.
 # Try to drop keyspace:
 {noformat}
 cqlsh drop keyspace Keyspace1;
 TSocket read 0 bytes
 {noformat}
 system.log:
 {noformat}
  INFO 15:10:46,516 Enqueuing flush of 
 Memtable-schema_columnfamilies@2127258371(0/0 serialized/live bytes, 1 ops)
  INFO 15:10:46,516 Writing Memtable-schema_columnfamilies@2127258371(0/0 
 serialized/live bytes, 1 ops)
  INFO 15:10:46,690 Completed flushing 
 /var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ic-6-Data.db
  (38 bytes) for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794574)
  INFO 15:10:46,692 Enqueuing flush of Memtable-schema_columns@1997964959(0/0 
 serialized/live bytes, 1 ops)
  INFO 15:10:46,693 Writing Memtable-schema_columns@1997964959(0/0 
 serialized/live bytes, 1 ops)
  INFO 15:10:46,857 Completed flushing 
 /var/lib/cassandra/data/system/schema_columns/system-schema_columns-ic-6-Data.db
  (38 bytes) for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794574)
  INFO 15:10:46,897 Enqueuing flush of Memtable-local@1366216652(98/98 
 serialized/live bytes, 3 ops)
  INFO 15:10:46,898 Writing Memtable-local@1366216652(98/98 serialized/live 
 bytes, 3 ops)
  INFO 15:10:47,064 Completed flushing 
 /var/lib/cassandra/data/system/local/system-local-ic-12-Data.db (139 bytes) 
 for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794845)
  INFO 15:10:48,956 Enqueuing flush of Memtable-local@432522279(46/46 
 serialized/live bytes, 1 ops)
  INFO 15:10:48,957 Writing Memtable-local@432522279(46/46 serialized/live 
 bytes, 1 ops)
  INFO 15:10:49,132 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 400882073/1094043713)bytes
  INFO 15:10:49,175 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 147514075/645675954)bytes
  INFO 15:10:49,185 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 223249644/609072261)bytes
  INFO 15:10:49,202 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 346471085/990388210)bytes
  INFO 15:10:49,215 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 294748503/2092376617)bytes
  INFO 15:10:49,257 Compaction interrupted: 
 Compaction@4d331c44-f018-302b-91c2-2dcf94c4bfad(Keyspace1, Standard1, 
 692722235/739328646)bytes
  INFO 15:10:49,285 Completed flushing 
 /var/lib/cassandra/data/system/local/system-local-ic-13-Data.db (82 bytes) 
 for commitlog position ReplayPosition(segmentId=1377867520699, 
 position=19794974)
  INFO 15:10:49,286 Compacting 
 [SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-10-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-13-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-12-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/system/local/system-local-ic-11-Data.db')]
 ERROR 15:10:49,287 Error occurred during processing of message.
 java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
 java.lang.AssertionError: 
 SSTableReader(path='/var/lib/cassandra/data/Keyspace1/Standard1/Keyspace1-Standard1-ic-78-Data.db')
  was already marked compacted
   at 
 org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:378)
   at 
 org.apache.cassandra.service.MigrationManager.announce(MigrationManager.java:281)
   at 
 org.apache.cassandra.service.MigrationManager.announceKeyspaceDrop(MigrationManager.java:262)
   at 
 org.apache.cassandra.cql.QueryProcessor.processStatement(QueryProcessor.java:718)
   at

[jira] [Commented] (CASSANDRA-5958) Unable to find property errors from snakeyaml are confusing

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

J.B. Langston commented on CASSANDRA-5958:
--

I just tested with 2.0.0-rc2 and the message is the same as before.

Unable to find property errors from snakeyaml are confusing
-

Key: CASSANDRA-5958
URL: https://issues.apache.org/jira/browse/CASSANDRA-5958
Project: Cassandra
Issue Type: Bug
Reporter: J.B. Langston
Priority: Minor

[jira] [Created] (CASSANDRA-5958) Unable to find property errors from snakeyaml are confusing

J.B. Langston created CASSANDRA-5958:


 Summary: Unable to find property errors from snakeyaml are 
confusing
 Key: CASSANDRA-5958
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5958
 Project: Cassandra
  Issue Type: Bug
Reporter: J.B. Langston
Priority: Minor


When an unexpected property is present in cassandra.yaml (e.g. after 
upgrading), snakeyaml outputs the following message:

Unable to find property 'some_property' on class: 
org.apache.cassandra.config.Config

The error message is kind of counterintuitive because at first glance it seems 
to suggest the property is missing from the yaml file, when in fact the error 
is caused by the *presence* of an unrecognized property.  I know if you read it 
carefully it says it can't find the property on the class, but this has 
confused more than one user.

I think we catch this exception and wrap it in another exception that says 
something like this:

Please remove 'some_property' from your cassandra.yaml. It is not recognized by 
this version of Cassandra.

--
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-4757) Expose bulk loading progress/status over jmx


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

Greg DeAngelis edited comment on CASSANDRA-4757 at 8/30/13 4:30 PM:


Sorry that was an oversight by me. I believe sstableloader uses an int so i'll 
follow that and will fix it later today.

  was (Author: gdeangel):
Sorry that was an oversight by me. I will fix that today.
  
 Expose bulk loading progress/status over jmx
 

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

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


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

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

[jira] [Created] (CASSANDRA-5959) CQL3 support for multi-column insert in a single operation (Batch Insert / Batch Mutate)

Les Hazlewood created CASSANDRA-5959:


 Summary: CQL3 support for multi-column insert in a single 
operation (Batch Insert / Batch Mutate)
 Key: CASSANDRA-5959
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5959
 Project: Cassandra
  Issue Type: New Feature
  Components: Core, Drivers
Reporter: Les Hazlewood


h3. Impetus for this Request

(from the original [question on 
StackOverflow|http://stackoverflow.com/questions/18522191/using-cassandra-and-cql3-how-do-you-insert-an-entire-wide-row-in-a-single-reque]):

I want to insert a single row with 50,000 columns into Cassandra 1.2.9. Before 
inserting, I have all the data for the entire row ready to go (in memory):

{code}
+-+--+--+--+--+---+
| | 0| 1| 2| ...  | 4 |
| row_id  +--+--+--+--+---+
| | text | text | text | ...  | text  |
+-+--+--+--|--+---+
{code}

The column names are integers, allowing slicing for pagination. The column 
values are a value at that particular index.

CQL3 table definition:

{code}
create table results (
row_id text,
index int,
value text,
primary key (row_id, index)
) 
with compact storage;
{code}

As I already have the row_id and all 50,000 name/value pairs in memory, I just 
want to insert a single row into Cassandra in a single request/operation so it 
is as fast as possible.

The only thing I can seem to find is to do execute the following 50,000 times:

{code}
INSERT INTO results (row_id, index, value) values (my_row_id, ?, ?);
{code}

where the first {{?}} is is an index counter ({{i}}) and the second {{?}} is 
the text value to store at location {{i}}.

With the Datastax Java Driver client and C* server on the same development 
machine, this took a full minute to execute.

Oddly enough, the same 50,000 insert statements in a [Datastax Java Driver 
Batch|http://www.datastax.com/drivers/java/apidocs/com/datastax/driver/core/querybuilder/QueryBuilder.html#batch(com.datastax.driver.core.Statement...)]
 on the same machine took 7.5 minutes.  I thought batches were supposed to be 
_faster_ than individual inserts?

We tried instead with a Thrift client (Astyanax) and the same insert via a 
[MutationBatch|http://netflix.github.io/astyanax/javadoc/com/netflix/astyanax/MutationBatch.html].
  This took _235 milliseconds_.


h3. Feature Request

As a result of this performance testing, this issue is to request that CQL3 
support batch mutation operations as a single operation (statement) to ensure 
the same speed/performance benefits as existing Thrift clients.

Example suggested syntax (based on the above example table/column family):

{code}
insert into results (row_id, (index,value)) values 
((0,text0), (1,text1), (2,text2), ..., (N,textN));
{code}

Each value in the {{values}} clause is a tuple.  The first tuple element is the 
column name, the second tuple element is the column value.  This seems to be 
the most simple/accurate representation of what happens during a batch 
insert/mutate.

Not having this CQL feature forced us to remove the Datastax Java Driver (which 
we liked) in favor of Astyanax because Astyanax supports this behavior.  We 
desire feature/performance parity between Thrift and CQL3/Datastax Java Driver, 
so we hope this request improves both CQL3 and the Driver.


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

[1/2] Revert CASSANDRA-5838

Updated Branches:
  refs/heads/trunk 14da6bca0 - 3205e5dbb


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3205e5db/test/unit/org/apache/cassandra/db/RowIterationTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/RowIterationTest.java 
b/test/unit/org/apache/cassandra/db/RowIterationTest.java
index 084be2d..c083b19 100644
--- a/test/unit/org/apache/cassandra/db/RowIterationTest.java
+++ b/test/unit/org/apache/cassandra/db/RowIterationTest.java
@@ -85,7 +85,7 @@ public class RowIterationTest extends SchemaLoader
 rm.apply();
 store.forceBlockingFlush();
 
-ColumnFamily cf = Util.getRangeSlice(store).get(0).cf;
+ColumnFamily cf = Util.getRangeSlice(store).iterator().next().cf;
 assert cf.deletionInfo().equals(delInfo2);
 }
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3205e5db/tools/stress/src/org/apache/cassandra/stress/Session.java
--
diff --git a/tools/stress/src/org/apache/cassandra/stress/Session.java 
b/tools/stress/src/org/apache/cassandra/stress/Session.java
index 5897552..49449eb 100644
--- a/tools/stress/src/org/apache/cassandra/stress/Session.java
+++ b/tools/stress/src/org/apache/cassandra/stress/Session.java
@@ -17,24 +17,17 @@
  */
 package org.apache.cassandra.stress;
 
-import java.io.BufferedReader;
-import java.io.FileInputStream;
-import java.io.FileNotFoundException;
-import java.io.FileOutputStream;
-import java.io.IOException;
-import java.io.InputStreamReader;
-import java.io.PrintStream;
-import java.io.Serializable;
+import java.io.*;
 import java.net.InetAddress;
 import java.net.UnknownHostException;
 import java.nio.ByteBuffer;
-import java.util.ArrayList;
-import java.util.Arrays;
-import java.util.HashMap;
-import java.util.List;
-import java.util.Map;
+import java.util.*;
 import java.util.concurrent.atomic.AtomicInteger;
 
+import org.apache.commons.cli.*;
+import org.apache.commons.lang3.StringUtils;
+
+import com.yammer.metrics.Metrics;
 import org.apache.cassandra.cli.transport.FramedTransportFactory;
 import org.apache.cassandra.config.CFMetaData;
 import org.apache.cassandra.config.EncryptionOptions;
@@ -43,18 +36,14 @@ import org.apache.cassandra.db.ColumnFamilyType;
 import org.apache.cassandra.db.marshal.*;
 import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.exceptions.SyntaxException;
-import org.apache.cassandra.metrics.CassandraMetricRegistry;
 import org.apache.cassandra.stress.util.CassandraClient;
 import org.apache.cassandra.thrift.*;
 import org.apache.cassandra.transport.SimpleClient;
 import org.apache.cassandra.utils.ByteBufferUtil;
-import org.apache.commons.cli.*;
-import org.apache.commons.lang3.StringUtils;
 import org.apache.thrift.protocol.TBinaryProtocol;
 import org.apache.thrift.transport.TSocket;
 import org.apache.thrift.transport.TTransport;
 import org.apache.thrift.transport.TTransportFactory;
-import com.codahale.metrics.MetricRegistry;
 
 public class Session implements Serializable
 {
@@ -69,7 +58,7 @@ public class Session implements Serializable
 
 public final AtomicInteger operations = new AtomicInteger();
 public final AtomicInteger keys = new AtomicInteger();
-public final com.codahale.metrics.Timer latency = 
CassandraMetricRegistry.get().timer(MetricRegistry.name(Session.class, 
latency));
+public final com.yammer.metrics.core.Timer latency = 
Metrics.newTimer(Session.class, latency);
 
 private static final String SSL_TRUSTSTORE = truststore;
 private static final String SSL_TRUSTSTORE_PW = truststore-password;

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3205e5db/tools/stress/src/org/apache/cassandra/stress/StressAction.java
--
diff --git a/tools/stress/src/org/apache/cassandra/stress/StressAction.java 
b/tools/stress/src/org/apache/cassandra/stress/StressAction.java
index 4c7489a..46005a1 100644
--- a/tools/stress/src/org/apache/cassandra/stress/StressAction.java
+++ b/tools/stress/src/org/apache/cassandra/stress/StressAction.java
@@ -24,7 +24,7 @@ import java.util.concurrent.TimeUnit;
 
 import com.google.common.util.concurrent.Uninterruptibles;
 import com.google.common.util.concurrent.RateLimiter;
-import com.codahale.metrics.Snapshot;
+import com.yammer.metrics.stats.Snapshot;
 import org.apache.cassandra.stress.operations.*;
 import org.apache.cassandra.stress.util.CassandraClient;
 import org.apache.cassandra.stress.util.Operation;

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3205e5db/tools/stress/src/org/apache/cassandra/stress/StressStatistics.java
--
diff --git a/tools/stress/src/org/apache/cassandra/stress/StressStatistics.java 
b/tools/stress/src/org/apache/cassandra/stress/StressStatistics.java

[jira] [Reopened] (CASSANDRA-5838) Upgrade metrics-core library


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

Jonathan Ellis reopened CASSANDRA-5838:
---


 Upgrade metrics-core library
 

 Key: CASSANDRA-5838
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5838
 Project: Cassandra
  Issue Type: Improvement
Reporter: Eugen Paraschiv
Assignee: Dave Brosius
Priority: Minor
 Fix For: 2.1

 Attachments: 5838-2.txt, 5838-3.txt, 5838.txt, Screen Shot 2013-08-27 
 at 2.53.39 PM.png


 Cassandra is now using [metrics|https://github.com/codahale/metrics] and is 
 depending on metrics-core 2.0.3. 
 It would be great to make the jump to the latest version of the library which 
 is 3.x - [latest is 
 3.0.1|http://search.maven.org/#search|gav|1|g%3A%22com.codahale.metrics%22%20AND%20a%3A%22metrics-core%22].
  

--
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-5954) Make nodetool ring print an error message and suggest nodetool status when vnodes are enabled

2013-08-30 Thread Brandon Williams (JIRA)


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

Brandon Williams commented on CASSANDRA-5954:
-

bq. We can get it from a system table right?

Yes, but then you'd have to calculate ownership yourself.

 Make nodetool ring print an error message and suggest nodetool status when 
 vnodes are enabled
 -

 Key: CASSANDRA-5954
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5954
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jonathan Ellis
Assignee: Lyuben Todorov
Priority: Minor
 Fix For: 2.0.1




--
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-5838) Upgrade metrics-core library


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

Jonathan Ellis commented on CASSANDRA-5838:
---

Will address 2.2 upgrade in CASSANDRA-5947.

 Upgrade metrics-core library
 

 Key: CASSANDRA-5838
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5838
 Project: Cassandra
  Issue Type: Improvement
Reporter: Eugen Paraschiv
Assignee: Dave Brosius
Priority: Minor
 Fix For: 2.1

 Attachments: 5838-2.txt, 5838-3.txt, 5838.txt, Screen Shot 2013-08-27 
 at 2.53.39 PM.png


 Cassandra is now using [metrics|https://github.com/codahale/metrics] and is 
 depending on metrics-core 2.0.3. 
 It would be great to make the jump to the latest version of the library which 
 is 3.x - [latest is 
 3.0.1|http://search.maven.org/#search|gav|1|g%3A%22com.codahale.metrics%22%20AND%20a%3A%22metrics-core%22].
  

--
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

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

Merge branch 'cassandra-2.0' into trunk


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

Branch: refs/heads/trunk
Commit: ca037b08e8fade6d34cd16d42dfa759de86eb1f1
Parents: 583d98b 2be4241
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Aug 30 13:55:47 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Aug 30 13:55:47 2013 -0500

--
 CHANGES.txt |   2 +
 lib/licenses/metrics-core-2.0.3.txt | 202 ---
 lib/licenses/metrics-core-2.2.0.txt | 202 +++
 lib/metrics-core-2.0.3.jar  | Bin 80800 - 0 bytes
 lib/metrics-core-2.2.0.jar  | Bin 0 - 82123 bytes
 5 files changed, 204 insertions(+), 202 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ca037b08/CHANGES.txt
--

[1/7] git commit: Upgrade metrics-core to version 2.2.0 patch by jbellis for CASSANDRA-5947

Updated Branches:
  refs/heads/cassandra-1.2 18be7fa87 - de1a91fe5
  refs/heads/cassandra-2.0 e7693fa92 - 2be424138
  refs/heads/trunk 3205e5dbb - ca037b08e


Upgrade metrics-core to version 2.2.0
patch by jbellis for CASSANDRA-5947


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

Branch: refs/heads/cassandra-1.2
Commit: de1a91fe5ecd4d06e5949c02e0d759e014f4f6ae
Parents: 18be7fa
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Aug 30 13:50:12 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Aug 30 13:50:12 2013 -0500

--
 CHANGES.txt |   1 +
 lib/licenses/metrics-core-2.0.3.txt | 202 ---
 lib/licenses/metrics-core-2.2.0.txt | 202 +++
 lib/metrics-core-2.0.3.jar  | Bin 80800 - 0 bytes
 lib/metrics-core-2.2.0.jar  | Bin 0 - 82123 bytes
 5 files changed, 203 insertions(+), 202 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/de1a91fe/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5cb1522..777d0d1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 1.2.10
+ * Upgrade metrics-core to version 2.2.0 (CASSANDRA-5947)
  * Add snitch, schema version, cluster, partitioner to JMX (CASSANDRA-5881)
  * Fix CqlRecordWriter with composite keys (CASSANDRA-5949)
  * Allow disabling SlabAllocator (CASSANDRA-5935)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/de1a91fe/lib/licenses/metrics-core-2.0.3.txt
--
diff --git a/lib/licenses/metrics-core-2.0.3.txt 
b/lib/licenses/metrics-core-2.0.3.txt
deleted file mode 100644
index e4ba404..000
--- a/lib/licenses/metrics-core-2.0.3.txt
+++ /dev/null
@@ -1,202 +0,0 @@
-
- Apache License
-   Version 2.0, January 2004
-http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-  License shall mean the terms and conditions for use, reproduction,
-  and distribution as defined by Sections 1 through 9 of this document.
-
-  Licensor shall mean the copyright owner or entity authorized by
-  the copyright owner that is granting the License.
-
-  Legal Entity shall mean the union of the acting entity and all
-  other entities that control, are controlled by, or are under common
-  control with that entity. For the purposes of this definition,
-  control means (i) the power, direct or indirect, to cause the
-  direction or management of such entity, whether by contract or
-  otherwise, or (ii) ownership of fifty percent (50%) or more of the
-  outstanding shares, or (iii) beneficial ownership of such entity.
-
-  You (or Your) shall mean an individual or Legal Entity
-  exercising permissions granted by this License.
-
-  Source form shall mean the preferred form for making modifications,
-  including but not limited to software source code, documentation
-  source, and configuration files.
-
-  Object form shall mean any form resulting from mechanical
-  transformation or translation of a Source form, including but
-  not limited to compiled object code, generated documentation,
-  and conversions to other media types.
-
-  Work shall mean the work of authorship, whether in Source or
-  Object form, made available under the License, as indicated by a
-  copyright notice that is included in or attached to the work
-  (an example is provided in the Appendix below).
-
-  Derivative Works shall mean any work, whether in Source or Object
-  form, that is based on (or derived from) the Work and for which the
-  editorial revisions, annotations, elaborations, or other modifications
-  represent, as a whole, an original work of authorship. For the purposes
-  of this License, Derivative Works shall not include works that remain
-  separable from, or merely link (or bind by name) to the interfaces of,
-  the Work and Derivative Works thereof.
-
-  Contribution shall mean any work of authorship, including
-  the original version of the Work and any modifications or additions
-  to that Work or Derivative Works thereof, that is intentionally
-  submitted to Licensor for inclusion in the Work by the copyright owner
-  or by an individual or Legal Entity authorized to submit on behalf of
-  the copyright owner. For the purposes of this definition,

[jira] [Commented] (CASSANDRA-5959) CQL3 support for multi-column insert in a single operation (Batch Insert / Batch Mutate)


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

Dave Brosius commented on CASSANDRA-5959:
-

here's a possibility. What if you were to use a Map type to insert all the 
values at once (or at least n of the values at once).

The problem is of course, that on read you don't want to have to read all 
50,000 columns. So what if cql had a slice function on collection types, such 
that you could do

select slice(my_map, 'first_val', 'last_val') from my_table where my_key = 
'foo';

this would return the my_map column back with just key value pairs in the slice 
range first_val to last_val ?

 CQL3 support for multi-column insert in a single operation (Batch Insert / 
 Batch Mutate)
 

 Key: CASSANDRA-5959
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5959
 Project: Cassandra
  Issue Type: New Feature
  Components: Core, Drivers
Reporter: Les Hazlewood
  Labels: CQL

 h3. Impetus for this Request
 (from the original [question on 
 StackOverflow|http://stackoverflow.com/questions/18522191/using-cassandra-and-cql3-how-do-you-insert-an-entire-wide-row-in-a-single-reque]):
 I want to insert a single row with 50,000 columns into Cassandra 1.2.9. 
 Before inserting, I have all the data for the entire row ready to go (in 
 memory):
 {code}
 +-+--+--+--+--+---+
 | | 0| 1| 2| ...  | 4 |
 | row_id  +--+--+--+--+---+
 | | text | text | text | ...  | text  |
 +-+--+--+--|--+---+
 {code}
 The column names are integers, allowing slicing for pagination. The column 
 values are a value at that particular index.
 CQL3 table definition:
 {code}
 create table results (
 row_id text,
 index int,
 value text,
 primary key (row_id, index)
 ) 
 with compact storage;
 {code}
 As I already have the row_id and all 50,000 name/value pairs in memory, I 
 just want to insert a single row into Cassandra in a single request/operation 
 so it is as fast as possible.
 The only thing I can seem to find is to do execute the following 50,000 times:
 {code}
 INSERT INTO results (row_id, index, value) values (my_row_id, ?, ?);
 {code}
 where the first {{?}} is is an index counter ({{i}}) and the second {{?}} is 
 the text value to store at location {{i}}.
 With the Datastax Java Driver client and C* server on the same development 
 machine, this took a full minute to execute.
 Oddly enough, the same 50,000 insert statements in a [Datastax Java Driver 
 Batch|http://www.datastax.com/drivers/java/apidocs/com/datastax/driver/core/querybuilder/QueryBuilder.html#batch(com.datastax.driver.core.Statement...)]
  on the same machine took 7.5 minutes.  I thought batches were supposed to be 
 _faster_ than individual inserts?
 We tried instead with a Thrift client (Astyanax) and the same insert via a 
 [MutationBatch|http://netflix.github.io/astyanax/javadoc/com/netflix/astyanax/MutationBatch.html].
   This took _235 milliseconds_.
 h3. Feature Request
 As a result of this performance testing, this issue is to request that CQL3 
 support batch mutation operations as a single operation (statement) to ensure 
 the same speed/performance benefits as existing Thrift clients.
 Example suggested syntax (based on the above example table/column family):
 {code}
 insert into results (row_id, (index,value)) values 
 ((0,text0), (1,text1), (2,text2), ..., (N,textN));
 {code}
 Each value in the {{values}} clause is a tuple.  The first tuple element is 
 the column name, the second tuple element is the column value.  This seems to 
 be the most simple/accurate representation of what happens during a batch 
 insert/mutate.
 Not having this CQL feature forced us to remove the Datastax Java Driver 
 (which we liked) in favor of Astyanax because Astyanax supports this 
 behavior.  We desire feature/performance parity between Thrift and 
 CQL3/Datastax Java Driver, so we hope this request improves both CQL3 and the 
 Driver.

--
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

[5/7] git commit: merge from 1.2

merge from 1.2


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

Branch: refs/heads/cassandra-2.0
Commit: 2be42413809b60968ed8b8301dd9a473f03f8885
Parents: e7693fa de1a91f
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Aug 30 13:55:06 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Aug 30 13:55:06 2013 -0500

--
 CHANGES.txt |   2 +
 lib/licenses/metrics-core-2.0.3.txt | 202 ---
 lib/licenses/metrics-core-2.2.0.txt | 202 +++
 lib/metrics-core-2.0.3.jar  | Bin 80800 - 0 bytes
 lib/metrics-core-2.2.0.jar  | Bin 0 - 82123 bytes
 5 files changed, 204 insertions(+), 202 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2be42413/CHANGES.txt
--
diff --cc CHANGES.txt
index 863214c,777d0d1..ee55941
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,19 -1,7 +1,21 @@@
 -1.2.10
 +2.0.1
 + * Improve leveled compaction's ability to find non-overlapping L0 compactions
 +   to work on concurrently (CASSANDRA-5921)
 + * Notify indexer of columns shadowed by range tombstones (CASSANDRA-5614)
 + * Log Merkle tree stats (CASSANDRA-2698)
 + * Switch from crc32 to adler32 for compressed sstable checksums 
(CASSANDRA-5862)
 + * Improve offheap memcpy performance (CASSANDRA-5884)
 + * Use a range aware scanner for cleanup (CASSANDRA-2524)
 + * Cleanup doesn't need to inspect sstables that contain only local data 
 +   (CASSANDRA-5722)
 + * Add ability for CQL3 to list partition keys (CASSANDRA-4536)
 + * Improve native protocol serialization (CASSANDRA-5664)
 + * Upgrade Thrift to 0.9.1 (CASSANDRA-5923)
 +Merged from 1.2:
+  * Upgrade metrics-core to version 2.2.0 (CASSANDRA-5947)
+  * Add snitch, schema version, cluster, partitioner to JMX (CASSANDRA-5881)
   * Fix CqlRecordWriter with composite keys (CASSANDRA-5949)
 + * Add snitch, schema version, cluster, partitioner to JMX (CASSANDRA-5881)
   * Allow disabling SlabAllocator (CASSANDRA-5935)
   * Make user-defined compaction JMX blocking (CASSANDRA-4952)
   * Fix streaming does not transfer wrapped range (CASSANDRA-5948)

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


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

Jonathan Ellis updated CASSANDRA-5947:
--

Component/s: Tools
   Priority: Minor  (was: Major)
   Assignee: Jonathan Ellis  (was: Brandon Williams)

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

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

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

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

[2/7] git commit: Upgrade metrics-core to version 2.2.0 patch by jbellis for CASSANDRA-5947

Upgrade metrics-core to version 2.2.0
patch by jbellis for CASSANDRA-5947


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

Branch: refs/heads/cassandra-2.0
Commit: de1a91fe5ecd4d06e5949c02e0d759e014f4f6ae
Parents: 18be7fa
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Aug 30 13:50:12 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Aug 30 13:50:12 2013 -0500

--
 CHANGES.txt |   1 +
 lib/licenses/metrics-core-2.0.3.txt | 202 ---
 lib/licenses/metrics-core-2.2.0.txt | 202 +++
 lib/metrics-core-2.0.3.jar  | Bin 80800 - 0 bytes
 lib/metrics-core-2.2.0.jar  | Bin 0 - 82123 bytes
 5 files changed, 203 insertions(+), 202 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/de1a91fe/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5cb1522..777d0d1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 1.2.10
+ * Upgrade metrics-core to version 2.2.0 (CASSANDRA-5947)
  * Add snitch, schema version, cluster, partitioner to JMX (CASSANDRA-5881)
  * Fix CqlRecordWriter with composite keys (CASSANDRA-5949)
  * Allow disabling SlabAllocator (CASSANDRA-5935)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/de1a91fe/lib/licenses/metrics-core-2.0.3.txt
--
diff --git a/lib/licenses/metrics-core-2.0.3.txt 
b/lib/licenses/metrics-core-2.0.3.txt
deleted file mode 100644
index e4ba404..000
--- a/lib/licenses/metrics-core-2.0.3.txt
+++ /dev/null
@@ -1,202 +0,0 @@
-
- Apache License
-   Version 2.0, January 2004
-http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-  License shall mean the terms and conditions for use, reproduction,
-  and distribution as defined by Sections 1 through 9 of this document.
-
-  Licensor shall mean the copyright owner or entity authorized by
-  the copyright owner that is granting the License.
-
-  Legal Entity shall mean the union of the acting entity and all
-  other entities that control, are controlled by, or are under common
-  control with that entity. For the purposes of this definition,
-  control means (i) the power, direct or indirect, to cause the
-  direction or management of such entity, whether by contract or
-  otherwise, or (ii) ownership of fifty percent (50%) or more of the
-  outstanding shares, or (iii) beneficial ownership of such entity.
-
-  You (or Your) shall mean an individual or Legal Entity
-  exercising permissions granted by this License.
-
-  Source form shall mean the preferred form for making modifications,
-  including but not limited to software source code, documentation
-  source, and configuration files.
-
-  Object form shall mean any form resulting from mechanical
-  transformation or translation of a Source form, including but
-  not limited to compiled object code, generated documentation,
-  and conversions to other media types.
-
-  Work shall mean the work of authorship, whether in Source or
-  Object form, made available under the License, as indicated by a
-  copyright notice that is included in or attached to the work
-  (an example is provided in the Appendix below).
-
-  Derivative Works shall mean any work, whether in Source or Object
-  form, that is based on (or derived from) the Work and for which the
-  editorial revisions, annotations, elaborations, or other modifications
-  represent, as a whole, an original work of authorship. For the purposes
-  of this License, Derivative Works shall not include works that remain
-  separable from, or merely link (or bind by name) to the interfaces of,
-  the Work and Derivative Works thereof.
-
-  Contribution shall mean any work of authorship, including
-  the original version of the Work and any modifications or additions
-  to that Work or Derivative Works thereof, that is intentionally
-  submitted to Licensor for inclusion in the Work by the copyright owner
-  or by an individual or Legal Entity authorized to submit on behalf of
-  the copyright owner. For the purposes of this definition, submitted
-  means any form of electronic, verbal, or written communication sent
-  to the Licensor or its representatives, including but not limited to

[3/7] git commit: Upgrade metrics-core to version 2.2.0 patch by jbellis for CASSANDRA-5947

Upgrade metrics-core to version 2.2.0
patch by jbellis for CASSANDRA-5947


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

Branch: refs/heads/trunk
Commit: de1a91fe5ecd4d06e5949c02e0d759e014f4f6ae
Parents: 18be7fa
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Aug 30 13:50:12 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Aug 30 13:50:12 2013 -0500

--
 CHANGES.txt |   1 +
 lib/licenses/metrics-core-2.0.3.txt | 202 ---
 lib/licenses/metrics-core-2.2.0.txt | 202 +++
 lib/metrics-core-2.0.3.jar  | Bin 80800 - 0 bytes
 lib/metrics-core-2.2.0.jar  | Bin 0 - 82123 bytes
 5 files changed, 203 insertions(+), 202 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/de1a91fe/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5cb1522..777d0d1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 1.2.10
+ * Upgrade metrics-core to version 2.2.0 (CASSANDRA-5947)
  * Add snitch, schema version, cluster, partitioner to JMX (CASSANDRA-5881)
  * Fix CqlRecordWriter with composite keys (CASSANDRA-5949)
  * Allow disabling SlabAllocator (CASSANDRA-5935)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/de1a91fe/lib/licenses/metrics-core-2.0.3.txt
--
diff --git a/lib/licenses/metrics-core-2.0.3.txt 
b/lib/licenses/metrics-core-2.0.3.txt
deleted file mode 100644
index e4ba404..000
--- a/lib/licenses/metrics-core-2.0.3.txt
+++ /dev/null
@@ -1,202 +0,0 @@
-
- Apache License
-   Version 2.0, January 2004
-http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-  License shall mean the terms and conditions for use, reproduction,
-  and distribution as defined by Sections 1 through 9 of this document.
-
-  Licensor shall mean the copyright owner or entity authorized by
-  the copyright owner that is granting the License.
-
-  Legal Entity shall mean the union of the acting entity and all
-  other entities that control, are controlled by, or are under common
-  control with that entity. For the purposes of this definition,
-  control means (i) the power, direct or indirect, to cause the
-  direction or management of such entity, whether by contract or
-  otherwise, or (ii) ownership of fifty percent (50%) or more of the
-  outstanding shares, or (iii) beneficial ownership of such entity.
-
-  You (or Your) shall mean an individual or Legal Entity
-  exercising permissions granted by this License.
-
-  Source form shall mean the preferred form for making modifications,
-  including but not limited to software source code, documentation
-  source, and configuration files.
-
-  Object form shall mean any form resulting from mechanical
-  transformation or translation of a Source form, including but
-  not limited to compiled object code, generated documentation,
-  and conversions to other media types.
-
-  Work shall mean the work of authorship, whether in Source or
-  Object form, made available under the License, as indicated by a
-  copyright notice that is included in or attached to the work
-  (an example is provided in the Appendix below).
-
-  Derivative Works shall mean any work, whether in Source or Object
-  form, that is based on (or derived from) the Work and for which the
-  editorial revisions, annotations, elaborations, or other modifications
-  represent, as a whole, an original work of authorship. For the purposes
-  of this License, Derivative Works shall not include works that remain
-  separable from, or merely link (or bind by name) to the interfaces of,
-  the Work and Derivative Works thereof.
-
-  Contribution shall mean any work of authorship, including
-  the original version of the Work and any modifications or additions
-  to that Work or Derivative Works thereof, that is intentionally
-  submitted to Licensor for inclusion in the Work by the copyright owner
-  or by an individual or Legal Entity authorized to submit on behalf of
-  the copyright owner. For the purposes of this definition, submitted
-  means any form of electronic, verbal, or written communication sent
-  to the Licensor or its representatives, including but not limited to
-

[4/7] git commit: merge from 1.2

merge from 1.2


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

Branch: refs/heads/trunk
Commit: 2be42413809b60968ed8b8301dd9a473f03f8885
Parents: e7693fa de1a91f
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Aug 30 13:55:06 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Aug 30 13:55:06 2013 -0500

--
 CHANGES.txt |   2 +
 lib/licenses/metrics-core-2.0.3.txt | 202 ---
 lib/licenses/metrics-core-2.2.0.txt | 202 +++
 lib/metrics-core-2.0.3.jar  | Bin 80800 - 0 bytes
 lib/metrics-core-2.2.0.jar  | Bin 0 - 82123 bytes
 5 files changed, 204 insertions(+), 202 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2be42413/CHANGES.txt
--
diff --cc CHANGES.txt
index 863214c,777d0d1..ee55941
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,19 -1,7 +1,21 @@@
 -1.2.10
 +2.0.1
 + * Improve leveled compaction's ability to find non-overlapping L0 compactions
 +   to work on concurrently (CASSANDRA-5921)
 + * Notify indexer of columns shadowed by range tombstones (CASSANDRA-5614)
 + * Log Merkle tree stats (CASSANDRA-2698)
 + * Switch from crc32 to adler32 for compressed sstable checksums 
(CASSANDRA-5862)
 + * Improve offheap memcpy performance (CASSANDRA-5884)
 + * Use a range aware scanner for cleanup (CASSANDRA-2524)
 + * Cleanup doesn't need to inspect sstables that contain only local data 
 +   (CASSANDRA-5722)
 + * Add ability for CQL3 to list partition keys (CASSANDRA-4536)
 + * Improve native protocol serialization (CASSANDRA-5664)
 + * Upgrade Thrift to 0.9.1 (CASSANDRA-5923)
 +Merged from 1.2:
+  * Upgrade metrics-core to version 2.2.0 (CASSANDRA-5947)
+  * Add snitch, schema version, cluster, partitioner to JMX (CASSANDRA-5881)
   * Fix CqlRecordWriter with composite keys (CASSANDRA-5949)
 + * Add snitch, schema version, cluster, partitioner to JMX (CASSANDRA-5881)
   * Allow disabling SlabAllocator (CASSANDRA-5935)
   * Make user-defined compaction JMX blocking (CASSANDRA-4952)
   * Fix streaming does not transfer wrapped range (CASSANDRA-5948)

[6/7] git commit: rename license file

rename license file


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

Branch: refs/heads/trunk
Commit: 583d98b475e366842267cf8e66927e261ed561c2
Parents: 3205e5d
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Aug 30 13:55:45 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Aug 30 13:55:45 2013 -0500

--
 lib/licenses/metrics-core-2.0.3.txt | 202 +++
 lib/licenses/metrics-core-3.0.1.txt | 202 ---
 2 files changed, 202 insertions(+), 202 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/583d98b4/lib/licenses/metrics-core-2.0.3.txt
--
diff --git a/lib/licenses/metrics-core-2.0.3.txt 
b/lib/licenses/metrics-core-2.0.3.txt
new file mode 100644
index 000..e4ba404
--- /dev/null
+++ b/lib/licenses/metrics-core-2.0.3.txt
@@ -0,0 +1,202 @@
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+  License shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  Licensor shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  Legal Entity shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  control means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  You (or Your) shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  Source form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  Object form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  Work shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  Derivative Works shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  Contribution shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, submitted
+  means any form of electronic, verbal, or written communication sent
+  to the Licensor or its representatives, including but not limited to
+  communication on electronic mailing lists, source code control systems,
+  and issue tracking systems that are managed by, or on behalf of, the
+  Licensor for the purpose of discussing and improving the Work, but
+  excluding communication that is conspicuously marked or otherwise
+  designated in writing by the copyright owner as Not a Contribution.
+
+  Contributor shall mean Licensor and any individual or Legal Entity
+  on behalf of whom a Contribution has been received by Licensor and
+  subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+  this License, each Contributor hereby grants to You a perpetual,
+  worldwide,

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

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

Jonathan Ellis resolved CASSANDRA-5947.
---

Resolution: Fixed
Fix Version/s: 2.0.1
1.2.10

Upgraded metrics-core to 2.2.0.

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

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

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

[jira] [Created] (CASSANDRA-5960) Remove 1.2 network compatibility code from 2.1

Aleksey Yeschenko created CASSANDRA-5960:


 Summary: Remove 1.2 network compatibility code from 2.1
 Key: CASSANDRA-5960
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5960
 Project: Cassandra
  Issue Type: Improvement
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Priority: Trivial
 Fix For: 2.1


Clean up the special-case code added for compatibility with 1.2 (reads) for the 
move to composites instead of supercolumns (CASSANDRA-3237, CASSANDRA-5123) and 
explicit timestamps in all read commands (CASSANDRA-5149).


--
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-5960) Remove 1.2 network compatibility code from 2.1


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

Aleksey Yeschenko updated CASSANDRA-5960:
-

Attachment: 5960.txt

 Remove 1.2 network compatibility code from 2.1
 --

 Key: CASSANDRA-5960
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5960
 Project: Cassandra
  Issue Type: Improvement
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Priority: Trivial
 Fix For: 2.1

 Attachments: 5960.txt


 Clean up the special-case code added for compatibility with 1.2 (reads) for 
 the move to composites instead of supercolumns (CASSANDRA-3237, 
 CASSANDRA-5123) and explicit timestamps in all read commands (CASSANDRA-5149).

--
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] [Resolved] (CASSANDRA-5838) Upgrade metrics-core library


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

Jonathan Ellis resolved CASSANDRA-5838.
---

Resolution: Later

bq. I'd be in favor of reverting this until we can figure out how to match the 
old format or confirm the current behavior (breaking) is absolutely what we 
want going forward.

reverted in 3205e5dbbc8fb8f365b72137cf1c1ea50f15cab6

 Upgrade metrics-core library
 

 Key: CASSANDRA-5838
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5838
 Project: Cassandra
  Issue Type: Improvement
Reporter: Eugen Paraschiv
Assignee: Dave Brosius
Priority: Minor
 Fix For: 2.1

 Attachments: 5838-2.txt, 5838-3.txt, 5838.txt, Screen Shot 2013-08-27 
 at 2.53.39 PM.png


 Cassandra is now using [metrics|https://github.com/codahale/metrics] and is 
 depending on metrics-core 2.0.3. 
 It would be great to make the jump to the latest version of the library which 
 is 3.x - [latest is 
 3.0.1|http://search.maven.org/#search|gav|1|g%3A%22com.codahale.metrics%22%20AND%20a%3A%22metrics-core%22].
  

--
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] [Resolved] (CASSANDRA-5959) CQL3 support for multi-column insert in a single operation (Batch Insert / Batch Mutate)


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

Aleksey Yeschenko resolved CASSANDRA-5959.
--

Resolution: Duplicate

CASSANDRA-4693 is what you want. You'll need 2.0, unfortunately.

 CQL3 support for multi-column insert in a single operation (Batch Insert / 
 Batch Mutate)
 

 Key: CASSANDRA-5959
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5959
 Project: Cassandra
  Issue Type: New Feature
  Components: Core, Drivers
Reporter: Les Hazlewood
  Labels: CQL

 h3. Impetus for this Request
 (from the original [question on 
 StackOverflow|http://stackoverflow.com/questions/18522191/using-cassandra-and-cql3-how-do-you-insert-an-entire-wide-row-in-a-single-reque]):
 I want to insert a single row with 50,000 columns into Cassandra 1.2.9. 
 Before inserting, I have all the data for the entire row ready to go (in 
 memory):
 {code}
 +-+--+--+--+--+---+
 | | 0| 1| 2| ...  | 4 |
 | row_id  +--+--+--+--+---+
 | | text | text | text | ...  | text  |
 +-+--+--+--|--+---+
 {code}
 The column names are integers, allowing slicing for pagination. The column 
 values are a value at that particular index.
 CQL3 table definition:
 {code}
 create table results (
 row_id text,
 index int,
 value text,
 primary key (row_id, index)
 ) 
 with compact storage;
 {code}
 As I already have the row_id and all 50,000 name/value pairs in memory, I 
 just want to insert a single row into Cassandra in a single request/operation 
 so it is as fast as possible.
 The only thing I can seem to find is to do execute the following 50,000 times:
 {code}
 INSERT INTO results (row_id, index, value) values (my_row_id, ?, ?);
 {code}
 where the first {{?}} is is an index counter ({{i}}) and the second {{?}} is 
 the text value to store at location {{i}}.
 With the Datastax Java Driver client and C* server on the same development 
 machine, this took a full minute to execute.
 Oddly enough, the same 50,000 insert statements in a [Datastax Java Driver 
 Batch|http://www.datastax.com/drivers/java/apidocs/com/datastax/driver/core/querybuilder/QueryBuilder.html#batch(com.datastax.driver.core.Statement...)]
  on the same machine took 7.5 minutes.  I thought batches were supposed to be 
 _faster_ than individual inserts?
 We tried instead with a Thrift client (Astyanax) and the same insert via a 
 [MutationBatch|http://netflix.github.io/astyanax/javadoc/com/netflix/astyanax/MutationBatch.html].
   This took _235 milliseconds_.
 h3. Feature Request
 As a result of this performance testing, this issue is to request that CQL3 
 support batch mutation operations as a single operation (statement) to ensure 
 the same speed/performance benefits as existing Thrift clients.
 Example suggested syntax (based on the above example table/column family):
 {code}
 insert into results (row_id, (index,value)) values 
 ((0,text0), (1,text1), (2,text2), ..., (N,textN));
 {code}
 Each value in the {{values}} clause is a tuple.  The first tuple element is 
 the column name, the second tuple element is the column value.  This seems to 
 be the most simple/accurate representation of what happens during a batch 
 insert/mutate.
 Not having this CQL feature forced us to remove the Datastax Java Driver 
 (which we liked) in favor of Astyanax because Astyanax supports this 
 behavior.  We desire feature/performance parity between Thrift and 
 CQL3/Datastax Java Driver, so we hope this request improves both CQL3 and the 
 Driver.

--
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-5959) CQL3 support for multi-column insert in a single operation (Batch Insert / Batch Mutate)


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

Les Hazlewood updated CASSANDRA-5959:
-

Description: 
h3. Impetus for this Request

(from the original [question on 
StackOverflow|http://stackoverflow.com/questions/18522191/using-cassandra-and-cql3-how-do-you-insert-an-entire-wide-row-in-a-single-reque]):

I want to insert a single row with 50,000 columns into Cassandra 1.2.9. Before 
inserting, I have all the data for the entire row ready to go (in memory):

{code}
+-+--+--+--+--+---+
| | 0| 1| 2| ...  | 4 |
| row_id  +--+--+--+--+---+
| | text | text | text | ...  | text  |
+-+--+--+--|--+---+
{code}

The column names are integers, allowing slicing for pagination. The column 
values are a value at that particular index.

CQL3 table definition:

{code}
create table results (
row_id text,
index int,
value text,
primary key (row_id, index)
) 
with compact storage;
{code}

As I already have the row_id and all 50,000 name/value pairs in memory, I just 
want to insert a single row into Cassandra in a single request/operation so it 
is as fast as possible.

The only thing I can seem to find is to do execute the following 50,000 times:

{code}
INSERT INTO results (row_id, index, value) values (my_row_id, ?, ?);
{code}

where the first {{?}} is is an index counter ({{i}}) and the second {{?}} is 
the text value to store at location {{i}}.

With the Datastax Java Driver client and C* server on the same development 
machine, this took a full minute to execute.

Oddly enough, the same 50,000 insert statements in a [Datastax Java Driver 
Batch|http://www.datastax.com/drivers/java/apidocs/com/datastax/driver/core/querybuilder/QueryBuilder.html#batch(com.datastax.driver.core.Statement...)]
 on the same machine took 7.5 minutes.  I thought batches were supposed to be 
_faster_ than individual inserts?

We tried instead with a Thrift client (Astyanax) and the same insert via a 
[MutationBatch|http://netflix.github.io/astyanax/javadoc/com/netflix/astyanax/MutationBatch.html].
  This took _235 milliseconds_.


h3. Feature Request

As a result of this performance testing, this issue is to request that CQL3 
support batch mutation operations as a single operation (statement) to ensure 
the same speed/performance benefits as existing Thrift clients.

Example suggested syntax (based on the above example table/column family):


{code}
insert into results (row_id, (index,value)) values 
((0,text0), (1,text1), (2,text2), ..., (N,textN));
{code}

Each value in the {{values}} clause is a tuple.  The first tuple element is the 
column name, the second tuple element is the column value.  This seems to be 
the most simple/accurate representation of what happens during a batch 
insert/mutate.

Not having this CQL feature forced us to remove the Datastax Java Driver (which 
we liked) in favor of Astyanax because Astyanax supports this behavior.  We 
desire feature/performance parity between Thrift and CQL3/Datastax Java Driver, 
so we hope this request improves both CQL3 and the Driver.


  was:
h3. Impetus for this Request

(from the original [question on 
StackOverflow|http://stackoverflow.com/questions/18522191/using-cassandra-and-cql3-how-do-you-insert-an-entire-wide-row-in-a-single-reque]):

I want to insert a single row with 50,000 columns into Cassandra 1.2.9. Before 
inserting, I have all the data for the entire row ready to go (in memory):

{code}
+-+--+--+--+--+---+
| | 0| 1| 2| ...  | 4 |
| row_id  +--+--+--+--+---+
| | text | text | text | ...  | text  |
+-+--+--+--|--+---+
{code}

The column names are integers, allowing slicing for pagination. The column 
values are a value at that particular index.

CQL3 table definition:

{code}
create table results (
row_id text,
index int,
value text,
primary key (row_id, index)
) 
with compact storage;
{code}

As I already have the row_id and all 50,000 name/value pairs in memory, I just 
want to insert a single row into Cassandra in a single request/operation so it 
is as fast as possible.

The only thing I can seem to find is to do execute the following 50,000 times:

{code}
INSERT INTO results (row_id, index, value) values (my_row_id, ?, ?);
{code}

where the first {{?}} is is an index counter ({{i}}) and the second {{?}} is 
the text value to store at location {{i}}.

With the Datastax Java Driver client and C* server on the same development 
machine, this took a full minute to execute.

Oddly enough, the same 50,000 insert statements in a [Datastax Java Driver 
Batch|http://www.datastax.com/drivers/java/apidocs/com/datastax/driver/core/querybuilder/QueryBuilder.html#batch(com.datastax.driver.core.Statement...)]

[jira] [Commented] (CASSANDRA-5084) Cassandra should expose connected client state via JMX

2013-08-30 Thread Brandon Williams (JIRA)


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

Brandon Williams commented on CASSANDRA-5084:
-

Are you calling ThriftSessionManager.instance.hashCode(); in CassandraServer 
just as a way of initializing it?

 Cassandra should expose connected client state via JMX
 --

 Key: CASSANDRA-5084
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5084
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Coli
Assignee: Suresh
Priority: Minor
  Labels: lhf
 Attachments: trunk-5084.patch


 There is currently no good way to determine or estimate how many clients are 
 connected to a cassandra node without using netstat or (if using sync thrift 
 server) counting threads. There is also no way to understand what state any 
 given connection is in. People regularly come into #cassandra/cassandra-user@ 
 and ask how to get the equivalent of a MySQL SHOW FULL PROCESSLIST.
 While I understand that feature parity with SHOW FULL 
 PROCESSLIST/information_schema.processlist is unlikely, even a few basic 
 metrics like number of connected clients or number of active clients 
 would greatly help with this operational information need.

--
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-5084) Cassandra should expose connected client state via JMX


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

Jonathan Ellis commented on CASSANDRA-5084:
---

Do you have to invoke a method or does just touching .instance work?  (Either 
way a comment would be nice.)

 Cassandra should expose connected client state via JMX
 --

 Key: CASSANDRA-5084
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5084
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Coli
Assignee: Suresh
Priority: Minor
  Labels: lhf
 Attachments: trunk-5084.patch


 There is currently no good way to determine or estimate how many clients are 
 connected to a cassandra node without using netstat or (if using sync thrift 
 server) counting threads. There is also no way to understand what state any 
 given connection is in. People regularly come into #cassandra/cassandra-user@ 
 and ask how to get the equivalent of a MySQL SHOW FULL PROCESSLIST.
 While I understand that feature parity with SHOW FULL 
 PROCESSLIST/information_schema.processlist is unlikely, even a few basic 
 metrics like number of connected clients or number of active clients 
 would greatly help with this operational information need.

--
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-2356) make the debian package never start by default


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

Jonathan Ellis commented on CASSANDRA-2356:
---

bq. if it's simple to disable auto-restart during upgrade (and only then) with 
a simple message to indicate the service needs to be started manually, this 
would seems like a good enough solution to me.

+1

 make the debian package never start by default
 --

 Key: CASSANDRA-2356
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2356
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: Jeremy Hanna
Priority: Minor
  Labels: debian, packaging
 Attachments: 2356.txt


 Currently the debian package that installs cassandra starts cassandra by 
 default.  It sounds like that is a standard debian packaging convention.  
 However, if you want to bootstrap a new node and want to configure it before 
 it creates any sort of state information, it's a pain.  I would think that 
 the common use case would be to have it install all of the init scripts and 
 such but *not* have it start up by default.  That way an admin can configure 
 cassandra with seed, token, host, etc. information and then start it.  That 
 makes it easier to programmatically do this as well - have chef/puppet 
 install cassandra, do some configuration, then do the service start.
 With the current setup, it sounds like cassandra creates state on startup 
 that has to be cleaned before a new configuration can take effect.  So the 
 process of installing turns into:
 * install debian package
 * shutdown cassandra
 * clean out state (data/log dirs)
 * configure cassandra
 * start cassandra
 That seems suboptimal for the default case, especially when trying to 
 automate new nodes being bootstrapped.
 Another case might be when a downed node comes back up and starts by default 
 and tries to claim a token that has already been claimed by another newly 
 bootstrapped node.  Rob is more familiar with that case so I'll let him 
 explain it in the comments.

--
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-5084) Cassandra should expose connected client state via JMX


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

Dave Brosius commented on CASSANDRA-5084:
-

it's just there to let the classloader do it's thing. stuff gets registered in 
the static block.

could do a myriad of things,

Class.forName(ThriftSessionManager.class.getName());
 etc



 Cassandra should expose connected client state via JMX
 --

 Key: CASSANDRA-5084
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5084
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Coli
Assignee: Suresh
Priority: Minor
  Labels: lhf
 Attachments: trunk-5084.patch


 There is currently no good way to determine or estimate how many clients are 
 connected to a cassandra node without using netstat or (if using sync thrift 
 server) counting threads. There is also no way to understand what state any 
 given connection is in. People regularly come into #cassandra/cassandra-user@ 
 and ask how to get the equivalent of a MySQL SHOW FULL PROCESSLIST.
 While I understand that feature parity with SHOW FULL 
 PROCESSLIST/information_schema.processlist is unlikely, even a few basic 
 metrics like number of connected clients or number of active clients 
 would greatly help with this operational information need.

--
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-5084) Cassandra should expose connected client state via JMX


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

Dave Brosius edited comment on CASSANDRA-5084 at 8/30/13 9:15 PM:
--

it's just there to let the classloader do it's thing. stuff gets registered in 
the static block.

could do a myriad of things,

Class.forName(ThriftSessionManager.class.getName());
or
ThriftSessionManager t = ThriftSessionManager.instance;
 etc, etc


  was (Author: dbrosius):
it's just there to let the classloader do it's thing. stuff gets registered 
in the static block.

could do a myriad of things,

Class.forName(ThriftSessionManager.class.getName());
 etc


  
 Cassandra should expose connected client state via JMX
 --

 Key: CASSANDRA-5084
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5084
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Coli
Assignee: Suresh
Priority: Minor
  Labels: lhf
 Attachments: trunk-5084.patch


 There is currently no good way to determine or estimate how many clients are 
 connected to a cassandra node without using netstat or (if using sync thrift 
 server) counting threads. There is also no way to understand what state any 
 given connection is in. People regularly come into #cassandra/cassandra-user@ 
 and ask how to get the equivalent of a MySQL SHOW FULL PROCESSLIST.
 While I understand that feature parity with SHOW FULL 
 PROCESSLIST/information_schema.processlist is unlikely, even a few basic 
 metrics like number of connected clients or number of active clients 
 would greatly help with this operational information need.

--
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-5084) Cassandra should expose connected client state via JMX


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

Dave Brosius edited comment on CASSANDRA-5084 at 8/30/13 9:16 PM:
--

it's just there to let the classloader do it's thing. stuff gets registered in 
the static block.

could do a myriad of things,

Class.forName(ThriftSessionManager.class.getName());
or
ThriftSessionManager t = ThriftSessionManager.instance;
 etc, etc

adding a no-op ThriftSessionManager.install() method in there, and calling it 
would be more self documenting. i suppose.

  was (Author: dbrosius):
it's just there to let the classloader do it's thing. stuff gets registered 
in the static block.

could do a myriad of things,

Class.forName(ThriftSessionManager.class.getName());
or
ThriftSessionManager t = ThriftSessionManager.instance;
 etc, etc

  
 Cassandra should expose connected client state via JMX
 --

 Key: CASSANDRA-5084
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5084
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Coli
Assignee: Suresh
Priority: Minor
  Labels: lhf
 Attachments: trunk-5084.patch


 There is currently no good way to determine or estimate how many clients are 
 connected to a cassandra node without using netstat or (if using sync thrift 
 server) counting threads. There is also no way to understand what state any 
 given connection is in. People regularly come into #cassandra/cassandra-user@ 
 and ask how to get the equivalent of a MySQL SHOW FULL PROCESSLIST.
 While I understand that feature parity with SHOW FULL 
 PROCESSLIST/information_schema.processlist is unlikely, even a few basic 
 metrics like number of connected clients or number of active clients 
 would greatly help with this operational information need.

--
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-5084) Cassandra should expose connected client state via JMX


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

Dave Brosius commented on CASSANDRA-5084:
-

yes

 Cassandra should expose connected client state via JMX
 --

 Key: CASSANDRA-5084
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5084
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Coli
Assignee: Suresh
Priority: Minor
  Labels: lhf
 Attachments: trunk-5084.patch


 There is currently no good way to determine or estimate how many clients are 
 connected to a cassandra node without using netstat or (if using sync thrift 
 server) counting threads. There is also no way to understand what state any 
 given connection is in. People regularly come into #cassandra/cassandra-user@ 
 and ask how to get the equivalent of a MySQL SHOW FULL PROCESSLIST.
 While I understand that feature parity with SHOW FULL 
 PROCESSLIST/information_schema.processlist is unlikely, even a few basic 
 metrics like number of connected clients or number of active clients 
 would greatly help with this operational information need.

--
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-5962) Support trigger parametrization

Aleksey Yeschenko created CASSANDRA-5962:


 Summary: Support trigger parametrization
 Key: CASSANDRA-5962
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5962
 Project: Cassandra
  Issue Type: Improvement
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 2.1


We don't have a convenient way to parametrize triggers, which limits their 
reusability and usability in general. For any configuration you have to rely on 
external config files.

We already have [trigger_options maptext, text] column in 
system.schema_triggers, all we need is to add the right syntax to CQL3 (CREATE 
TRIGGER foo ON bar USING class WITH options = {..}) and modify ITrigger to 
support it.

Setting fixver to 2.1, but might move to 2.0.x later.

--
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-5959) CQL3 support for multi-column insert in a single operation (Batch Insert / Batch Mutate)


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

Les Hazlewood commented on CASSANDRA-5959:
--

[~iamaleksey] Do you expect this to have the same performance as a Batch Mutate?

 CQL3 support for multi-column insert in a single operation (Batch Insert / 
 Batch Mutate)
 

 Key: CASSANDRA-5959
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5959
 Project: Cassandra
  Issue Type: New Feature
  Components: Core, Drivers
Reporter: Les Hazlewood
  Labels: CQL

 h3. Impetus for this Request
 (from the original [question on 
 StackOverflow|http://stackoverflow.com/questions/18522191/using-cassandra-and-cql3-how-do-you-insert-an-entire-wide-row-in-a-single-reque]):
 I want to insert a single row with 50,000 columns into Cassandra 1.2.9. 
 Before inserting, I have all the data for the entire row ready to go (in 
 memory):
 {code}
 +-+--+--+--+--+---+
 | | 0| 1| 2| ...  | 4 |
 | row_id  +--+--+--+--+---+
 | | text | text | text | ...  | text  |
 +-+--+--+--|--+---+
 {code}
 The column names are integers, allowing slicing for pagination. The column 
 values are a value at that particular index.
 CQL3 table definition:
 {code}
 create table results (
 row_id text,
 index int,
 value text,
 primary key (row_id, index)
 ) 
 with compact storage;
 {code}
 As I already have the row_id and all 50,000 name/value pairs in memory, I 
 just want to insert a single row into Cassandra in a single request/operation 
 so it is as fast as possible.
 The only thing I can seem to find is to do execute the following 50,000 times:
 {code}
 INSERT INTO results (row_id, index, value) values (my_row_id, ?, ?);
 {code}
 where the first {{?}} is is an index counter ({{i}}) and the second {{?}} is 
 the text value to store at location {{i}}.
 With the Datastax Java Driver client and C* server on the same development 
 machine, this took a full minute to execute.
 Oddly enough, the same 50,000 insert statements in a [Datastax Java Driver 
 Batch|http://www.datastax.com/drivers/java/apidocs/com/datastax/driver/core/querybuilder/QueryBuilder.html#batch(com.datastax.driver.core.Statement...)]
  on the same machine took 7.5 minutes.  I thought batches were supposed to be 
 _faster_ than individual inserts?
 We tried instead with a Thrift client (Astyanax) and the same insert via a 
 [MutationBatch|http://netflix.github.io/astyanax/javadoc/com/netflix/astyanax/MutationBatch.html].
   This took _235 milliseconds_.
 h3. Feature Request
 As a result of this performance testing, this issue is to request that CQL3 
 support batch mutation operations as a single operation (statement) to ensure 
 the same speed/performance benefits as existing Thrift clients.
 Example suggested syntax (based on the above example table/column family):
 {code}
 insert into results (row_id, (index,value)) values 
 ((0,text0), (1,text1), (2,text2), ..., (N,textN));
 {code}
 Each value in the {{values}} clause is a tuple.  The first tuple element is 
 the column name, the second tuple element is the column value.  This seems to 
 be the most simple/accurate representation of what happens during a batch 
 insert/mutate.
 Not having this CQL feature forced us to remove the Datastax Java Driver 
 (which we liked) in favor of Astyanax because Astyanax supports this 
 behavior.  We desire feature/performance parity between Thrift and 
 CQL3/Datastax Java Driver, so we hope this request improves both CQL3 and the 
 Driver.

--
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-5959) CQL3 support for multi-column insert in a single operation (Batch Insert / Batch Mutate)


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

Aleksey Yeschenko commented on CASSANDRA-5959:
--

[~lhazlewood] It's going to be about as fast as any thrift client (maybe 
slightly faster, maybe slightly slower).

 CQL3 support for multi-column insert in a single operation (Batch Insert / 
 Batch Mutate)
 

 Key: CASSANDRA-5959
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5959
 Project: Cassandra
  Issue Type: New Feature
  Components: Core, Drivers
Reporter: Les Hazlewood
  Labels: CQL

 h3. Impetus for this Request
 (from the original [question on 
 StackOverflow|http://stackoverflow.com/questions/18522191/using-cassandra-and-cql3-how-do-you-insert-an-entire-wide-row-in-a-single-reque]):
 I want to insert a single row with 50,000 columns into Cassandra 1.2.9. 
 Before inserting, I have all the data for the entire row ready to go (in 
 memory):
 {code}
 +-+--+--+--+--+---+
 | | 0| 1| 2| ...  | 4 |
 | row_id  +--+--+--+--+---+
 | | text | text | text | ...  | text  |
 +-+--+--+--|--+---+
 {code}
 The column names are integers, allowing slicing for pagination. The column 
 values are a value at that particular index.
 CQL3 table definition:
 {code}
 create table results (
 row_id text,
 index int,
 value text,
 primary key (row_id, index)
 ) 
 with compact storage;
 {code}
 As I already have the row_id and all 50,000 name/value pairs in memory, I 
 just want to insert a single row into Cassandra in a single request/operation 
 so it is as fast as possible.
 The only thing I can seem to find is to do execute the following 50,000 times:
 {code}
 INSERT INTO results (row_id, index, value) values (my_row_id, ?, ?);
 {code}
 where the first {{?}} is is an index counter ({{i}}) and the second {{?}} is 
 the text value to store at location {{i}}.
 With the Datastax Java Driver client and C* server on the same development 
 machine, this took a full minute to execute.
 Oddly enough, the same 50,000 insert statements in a [Datastax Java Driver 
 Batch|http://www.datastax.com/drivers/java/apidocs/com/datastax/driver/core/querybuilder/QueryBuilder.html#batch(com.datastax.driver.core.Statement...)]
  on the same machine took 7.5 minutes.  I thought batches were supposed to be 
 _faster_ than individual inserts?
 We tried instead with a Thrift client (Astyanax) and the same insert via a 
 [MutationBatch|http://netflix.github.io/astyanax/javadoc/com/netflix/astyanax/MutationBatch.html].
   This took _235 milliseconds_.
 h3. Feature Request
 As a result of this performance testing, this issue is to request that CQL3 
 support batch mutation operations as a single operation (statement) to ensure 
 the same speed/performance benefits as existing Thrift clients.
 Example suggested syntax (based on the above example table/column family):
 {code}
 insert into results (row_id, (index,value)) values 
 ((0,text0), (1,text1), (2,text2), ..., (N,textN));
 {code}
 Each value in the {{values}} clause is a tuple.  The first tuple element is 
 the column name, the second tuple element is the column value.  This seems to 
 be the most simple/accurate representation of what happens during a batch 
 insert/mutate.
 Not having this CQL feature forced us to remove the Datastax Java Driver 
 (which we liked) in favor of Astyanax because Astyanax supports this 
 behavior.  We desire feature/performance parity between Thrift and 
 CQL3/Datastax Java Driver, so we hope this request improves both CQL3 and the 
 Driver.

--
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-5961) ant test should only show WARN+ on stdout

Jonathan Ellis created CASSANDRA-5961:
-

 Summary: ant test should only show WARN+ on stdout
 Key: CASSANDRA-5961
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5961
 Project: Cassandra
  Issue Type: Bug
  Components: Tests
Reporter: Jonathan Ellis
Assignee: Dave Brosius
Priority: Minor
 Fix For: 2.1


We had log4j configured to only output WARN or ERROR messages on stdout during 
ant test.  Would be nice to get the same behavior on trunk.

--
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-5959) CQL3 support for multi-column insert in a single operation (Batch Insert / Batch Mutate)


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

Les Hazlewood commented on CASSANDRA-5959:
--

[~dbros...@apache.org] While the suggestion to support slice queries on a 
Cassandra collection would work for my particular example use case, I don't 
think it would be the ideal solution for C* in general: the suggested solution 
would not work for any collection larger than 65,535 elements since that is the 
C* max collection size.  If I choose to use a wide row for more columns, I'd 
expect the query to work on that as well.

Thanks for the idea!

 CQL3 support for multi-column insert in a single operation (Batch Insert / 
 Batch Mutate)
 

 Key: CASSANDRA-5959
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5959
 Project: Cassandra
  Issue Type: New Feature
  Components: Core, Drivers
Reporter: Les Hazlewood
  Labels: CQL

 h3. Impetus for this Request
 (from the original [question on 
 StackOverflow|http://stackoverflow.com/questions/18522191/using-cassandra-and-cql3-how-do-you-insert-an-entire-wide-row-in-a-single-reque]):
 I want to insert a single row with 50,000 columns into Cassandra 1.2.9. 
 Before inserting, I have all the data for the entire row ready to go (in 
 memory):
 {code}
 +-+--+--+--+--+---+
 | | 0| 1| 2| ...  | 4 |
 | row_id  +--+--+--+--+---+
 | | text | text | text | ...  | text  |
 +-+--+--+--|--+---+
 {code}
 The column names are integers, allowing slicing for pagination. The column 
 values are a value at that particular index.
 CQL3 table definition:
 {code}
 create table results (
 row_id text,
 index int,
 value text,
 primary key (row_id, index)
 ) 
 with compact storage;
 {code}
 As I already have the row_id and all 50,000 name/value pairs in memory, I 
 just want to insert a single row into Cassandra in a single request/operation 
 so it is as fast as possible.
 The only thing I can seem to find is to do execute the following 50,000 times:
 {code}
 INSERT INTO results (row_id, index, value) values (my_row_id, ?, ?);
 {code}
 where the first {{?}} is is an index counter ({{i}}) and the second {{?}} is 
 the text value to store at location {{i}}.
 With the Datastax Java Driver client and C* server on the same development 
 machine, this took a full minute to execute.
 Oddly enough, the same 50,000 insert statements in a [Datastax Java Driver 
 Batch|http://www.datastax.com/drivers/java/apidocs/com/datastax/driver/core/querybuilder/QueryBuilder.html#batch(com.datastax.driver.core.Statement...)]
  on the same machine took 7.5 minutes.  I thought batches were supposed to be 
 _faster_ than individual inserts?
 We tried instead with a Thrift client (Astyanax) and the same insert via a 
 [MutationBatch|http://netflix.github.io/astyanax/javadoc/com/netflix/astyanax/MutationBatch.html].
   This took _235 milliseconds_.
 h3. Feature Request
 As a result of this performance testing, this issue is to request that CQL3 
 support batch mutation operations as a single operation (statement) to ensure 
 the same speed/performance benefits as existing Thrift clients.
 Example suggested syntax (based on the above example table/column family):
 {code}
 insert into results (row_id, (index,value)) values 
 ((0,text0), (1,text1), (2,text2), ..., (N,textN));
 {code}
 Each value in the {{values}} clause is a tuple.  The first tuple element is 
 the column name, the second tuple element is the column value.  This seems to 
 be the most simple/accurate representation of what happens during a batch 
 insert/mutate.
 Not having this CQL feature forced us to remove the Datastax Java Driver 
 (which we liked) in favor of Astyanax because Astyanax supports this 
 behavior.  We desire feature/performance parity between Thrift and 
 CQL3/Datastax Java Driver, so we hope this request improves both CQL3 and the 
 Driver.

--
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-5963) Require superuser status for adding triggers

Aleksey Yeschenko created CASSANDRA-5963:


 Summary: Require superuser status for adding triggers
 Key: CASSANDRA-5963
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5963
 Project: Cassandra
  Issue Type: Improvement
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 2.0.1


You can do anything from within ITrigger.augment(), bypassing any authorization 
checks. The only fix is to require superuser status for CREATE TRIGGER and CF 
updates via Thrift that involve triggers.

--
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-5964) cqlsh raises a ValueError when connecting to Cassandra running in Eclipse

Greg DeAngelis created CASSANDRA-5964:
-

 Summary: cqlsh raises a ValueError when connecting to Cassandra 
running in Eclipse
 Key: CASSANDRA-5964
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5964
 Project: Cassandra
  Issue Type: Bug
Reporter: Greg DeAngelis
Priority: Minor


The release_version is set to 'Unknown' in system.local so the version parsing 
logic fails.

Traceback (most recent call last):
  File ./cqlsh, line 2027, in module
main(*read_options(sys.argv[1:], os.environ))
  File ./cqlsh, line 2013, in main
display_float_precision=options.float_precision)
  File ./cqlsh, line 486, in __init__
self.get_connection_versions()
  File ./cqlsh, line 580, in get_connection_versions
self.cass_ver_tuple = tuple(map(int, vers['build'].split('-', 
1)[0].split('.')[:3]))
ValueError: invalid literal for int() with base 10: 'Unknown'

--
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-5964) cqlsh raises a ValueError when connecting to Cassandra running in Eclipse


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

Greg DeAngelis updated CASSANDRA-5964:
--

Attachment: CASSANDRA-5964.patch

The error raised by cqlsh is a bit friendlier and I added an option 
--unknownversion to allow cqlsh to pass the connection version parsing if the 
version is 'Unknown'.

 cqlsh raises a ValueError when connecting to Cassandra running in Eclipse
 -

 Key: CASSANDRA-5964
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5964
 Project: Cassandra
  Issue Type: Bug
Reporter: Greg DeAngelis
Priority: Minor
 Attachments: CASSANDRA-5964.patch


 The release_version is set to 'Unknown' in system.local so the version 
 parsing logic fails.
 Traceback (most recent call last):
   File ./cqlsh, line 2027, in module
 main(*read_options(sys.argv[1:], os.environ))
   File ./cqlsh, line 2013, in main
 display_float_precision=options.float_precision)
   File ./cqlsh, line 486, in __init__
 self.get_connection_versions()
   File ./cqlsh, line 580, in get_connection_versions
 self.cass_ver_tuple = tuple(map(int, vers['build'].split('-', 
 1)[0].split('.')[:3]))
 ValueError: invalid literal for int() with base 10: 'Unknown'

--
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 ThresholdFilter for stderr for tests for cassandra-5961

2013-08-30 Thread dbrosius

Updated Branches:
  refs/heads/trunk ca037b08e - 0ec481bd6


add ThresholdFilter for stderr for tests for cassandra-5961


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

Branch: refs/heads/trunk
Commit: 0ec481bd64874e8e03d046c5177dcf0f4a64e500
Parents: ca037b0
Author: Dave Brosius dbros...@apache.org
Authored: Fri Aug 30 20:39:20 2013 -0400
Committer: Dave Brosius dbros...@apache.org
Committed: Fri Aug 30 20:39:20 2013 -0400

--
 test/conf/logback-test.xml | 3 +++
 1 file changed, 3 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0ec481bd/test/conf/logback-test.xml
--
diff --git a/test/conf/logback-test.xml b/test/conf/logback-test.xml
index dcfbb92..ff953d7 100644
--- a/test/conf/logback-test.xml
+++ b/test/conf/logback-test.xml
@@ -19,6 +19,9 @@
 encoder
   pattern%-5level %date{HH:mm:ss,SSS} %msg%n/pattern
 /encoder
+filter class=ch.qos.logback.classic.filter.ThresholdFilter
+  levelWARN/level
+/filter
   /appender
 
   root level=DEBUG

[jira] [Resolved] (CASSANDRA-5961) ant test should only show WARN+ on stdout


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

Dave Brosius resolved CASSANDRA-5961.
-

Resolution: Fixed

add threshold filter on stderr for tests to WARN, committed to trunk as commit 
0ec481bd64874e8e03d046c5177dcf0f4a64e500 

 ant test should only show WARN+ on stdout
 -

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


 We had log4j configured to only output WARN or ERROR messages on stdout 
 during ant test.  Would be nice to get the same behavior on trunk.

--
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-5964) cqlsh raises a ValueError when connecting to Cassandra running in Eclipse


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

Greg DeAngelis updated CASSANDRA-5964:
--

Attachment: (was: CASSANDRA-5964.patch)

 cqlsh raises a ValueError when connecting to Cassandra running in Eclipse
 -

 Key: CASSANDRA-5964
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5964
 Project: Cassandra
  Issue Type: Bug
Reporter: Greg DeAngelis
Priority: Minor

 The release_version is set to 'Unknown' in system.local so the version 
 parsing logic fails.
 Traceback (most recent call last):
   File ./cqlsh, line 2027, in module
 main(*read_options(sys.argv[1:], os.environ))
   File ./cqlsh, line 2013, in main
 display_float_precision=options.float_precision)
   File ./cqlsh, line 486, in __init__
 self.get_connection_versions()
   File ./cqlsh, line 580, in get_connection_versions
 self.cass_ver_tuple = tuple(map(int, vers['build'].split('-', 
 1)[0].split('.')[:3]))
 ValueError: invalid literal for int() with base 10: 'Unknown'

--
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] [Issue Comment Deleted] (CASSANDRA-5964) cqlsh raises a ValueError when connecting to Cassandra running in Eclipse


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

Greg DeAngelis updated CASSANDRA-5964:
--

Comment: was deleted

(was: The error raised by cqlsh is a bit friendlier and I added an option 
--unknownversion to allow cqlsh to pass the connection version parsing if the 
version is 'Unknown'.)

 cqlsh raises a ValueError when connecting to Cassandra running in Eclipse
 -

 Key: CASSANDRA-5964
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5964
 Project: Cassandra
  Issue Type: Bug
Reporter: Greg DeAngelis
Priority: Minor

 The release_version is set to 'Unknown' in system.local so the version 
 parsing logic fails.
 Traceback (most recent call last):
   File ./cqlsh, line 2027, in module
 main(*read_options(sys.argv[1:], os.environ))
   File ./cqlsh, line 2013, in main
 display_float_precision=options.float_precision)
   File ./cqlsh, line 486, in __init__
 self.get_connection_versions()
   File ./cqlsh, line 580, in get_connection_versions
 self.cass_ver_tuple = tuple(map(int, vers['build'].split('-', 
 1)[0].split('.')[:3]))
 ValueError: invalid literal for int() with base 10: 'Unknown'

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

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

2013-08-30 Thread Michael Kjellman (JIRA)


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

Michael Kjellman updated CASSANDRA-5883:


Attachment: 5883-additional1.txt

remove additional references to log4j

 Switch to Logback
 -

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

 Attachments: 5883-1.txt, 5883-additional1.txt, 5883.txt


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

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

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

2013-08-30 Thread Michael Kjellman (JIRA)


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

Michael Kjellman reopened CASSANDRA-5883:
-


looks like a few references to log4j were left around. i went thru and tried to 
clean them all up. attached a diff

 Switch to Logback
 -

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

 Attachments: 5883-1.txt, 5883-additional1.txt, 5883.txt


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

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

[jira] [Created] (CASSANDRA-5965) IndexSummary load fails when empty key exists in summary

2013-08-30 Thread Yuki Morishita (JIRA)

Yuki Morishita created CASSANDRA-5965:
-

 Summary: IndexSummary load fails when empty key exists in summary
 Key: CASSANDRA-5965
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5965
 Project: Cassandra
  Issue Type: Bug
Reporter: Yuki Morishita
 Attachments: 0001-Add-IndexSummary-test.patch

IndexSummary load fails with the following error when empty key is added to 
summary:

{code}
ERROR [SSTableBatchOpen:1] 2013-08-30 20:17:41,210 CassandraDaemon.java (line 
192) Exception in thread Thread[SSTableBatchOpen:1,5,main]
java.lang.AssertionError
at 
org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:401)
at 
org.apache.cassandra.io.sstable.IndexSummary$IndexSummarySerializer.deserialize(IndexSummary.java:124)
at 
org.apache.cassandra.io.sstable.SSTableReader.loadSummary(SSTableReader.java:491)
at 
org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:388)
at 
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:198)
at 
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:157)
at 
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:262)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
{code}

I think this is typically caused by indexing empty column, and then the key in 
index columnfamily is added to its IndexSummary.

--
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-5965) IndexSummary load fails when empty key exists in summary

2013-08-30 Thread Yuki Morishita (JIRA)


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

Yuki Morishita updated CASSANDRA-5965:
--

Attachment: 0001-Add-IndexSummary-test.patch

Attaching unit test case to reproduce.

 IndexSummary load fails when empty key exists in summary
 

 Key: CASSANDRA-5965
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5965
 Project: Cassandra
  Issue Type: Bug
Reporter: Yuki Morishita
 Attachments: 0001-Add-IndexSummary-test.patch


 IndexSummary load fails with the following error when empty key is added to 
 summary:
 {code}
 ERROR [SSTableBatchOpen:1] 2013-08-30 20:17:41,210 CassandraDaemon.java (line 
 192) Exception in thread Thread[SSTableBatchOpen:1,5,main]
 java.lang.AssertionError
 at 
 org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:401)
 at 
 org.apache.cassandra.io.sstable.IndexSummary$IndexSummarySerializer.deserialize(IndexSummary.java:124)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.loadSummary(SSTableReader.java:491)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:388)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:198)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:157)
 at 
 org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:262)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:724)
 {code}
 I think this is typically caused by indexing empty column, and then the key 
 in index columnfamily is added to its IndexSummary.

--
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-5965) IndexSummary load fails when empty key exists in summary

2013-08-30 Thread Yuki Morishita (JIRA)


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

Yuki Morishita updated CASSANDRA-5965:
--

Attachment: 5965-1.2.txt

Patch attached to handle key of length 0.

 IndexSummary load fails when empty key exists in summary
 

 Key: CASSANDRA-5965
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5965
 Project: Cassandra
  Issue Type: Bug
Reporter: Yuki Morishita
 Attachments: 0001-Add-IndexSummary-test.patch, 5965-1.2.txt


 IndexSummary load fails with the following error when empty key is added to 
 summary:
 {code}
 ERROR [SSTableBatchOpen:1] 2013-08-30 20:17:41,210 CassandraDaemon.java (line 
 192) Exception in thread Thread[SSTableBatchOpen:1,5,main]
 java.lang.AssertionError
 at 
 org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:401)
 at 
 org.apache.cassandra.io.sstable.IndexSummary$IndexSummarySerializer.deserialize(IndexSummary.java:124)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.loadSummary(SSTableReader.java:491)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:388)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:198)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:157)
 at 
 org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:262)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:724)
 {code}
 I think this is typically caused by indexing empty column, and then the key 
 in index columnfamily is added to its IndexSummary.

--
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-5965) IndexSummary load fails when empty key exists in summary


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

Jonathan Ellis commented on CASSANDRA-5965:
---

+1

Also suggest adding a {{: length}} to the assert, which will make diagnosing 
such oversights easier in the future.

 IndexSummary load fails when empty key exists in summary
 

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

 Attachments: 0001-Add-IndexSummary-test.patch, 5965-1.2.txt


 IndexSummary load fails with the following error when empty key is added to 
 summary:
 {code}
 ERROR [SSTableBatchOpen:1] 2013-08-30 20:17:41,210 CassandraDaemon.java (line 
 192) Exception in thread Thread[SSTableBatchOpen:1,5,main]
 java.lang.AssertionError
 at 
 org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:401)
 at 
 org.apache.cassandra.io.sstable.IndexSummary$IndexSummarySerializer.deserialize(IndexSummary.java:124)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.loadSummary(SSTableReader.java:491)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:388)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:198)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:157)
 at 
 org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:262)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:724)
 {code}
 I think this is typically caused by indexing empty column, and then the key 
 in index columnfamily is added to its IndexSummary.

--
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-5952) report compression ratio via nodetool cfstats

2013-08-30 Thread Vijay (JIRA)


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

Vijay updated CASSANDRA-5952:
-

Attachment: 0001-CASSANDRA-5952.patch

One liner change to expose via NT, Thanks!

 report compression ratio via nodetool cfstats
 -

 Key: CASSANDRA-5952
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5952
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Robert Coli
Assignee: Vijay
Priority: Trivial
 Attachments: 0001-CASSANDRA-5952.patch


 CASSANDRA-3393 adds a getCompressionRatio JMX call, and was originally 
 supposed to also expose this value per CF via nodetool cfstats.
 However, the nodetool cfstats part was not done in CASSANDRA-3393. This 
 ticket serves as a request to expose this valuable data about compression via 
 nodetool cfstats.
 (cc: [~vijay2...@yahoo.com], who did the CASSANDRA-3393 work)

--
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-5964) cqlsh raises a ValueError when connecting to Cassandra running in Eclipse


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

Dave Brosius updated CASSANDRA-5964:


Attachment: 5964.txt

generate the version.properties file into ${basedir}/src/resources, and allow 
it to be copied into classes by the regular build process. Doing this allows 
eclipse/idea to see it as a resource that needs copying during build as well, 
and so they don't just delete the file on scrub-build. The IDE should just have 
src/resources as a src directory.  (Against trunk)

 cqlsh raises a ValueError when connecting to Cassandra running in Eclipse
 -

 Key: CASSANDRA-5964
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5964
 Project: Cassandra
  Issue Type: Bug
Reporter: Greg DeAngelis
Priority: Minor
 Attachments: 5964.txt


 The release_version is set to 'Unknown' in system.local so the version 
 parsing logic fails.
 Traceback (most recent call last):
   File ./cqlsh, line 2027, in module
 main(*read_options(sys.argv[1:], os.environ))
   File ./cqlsh, line 2013, in main
 display_float_precision=options.float_precision)
   File ./cqlsh, line 486, in __init__
 self.get_connection_versions()
   File ./cqlsh, line 580, in get_connection_versions
 self.cass_ver_tuple = tuple(map(int, vers['build'].split('-', 
 1)[0].split('.')[:3]))
 ValueError: invalid literal for int() with base 10: 'Unknown'

--
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-5952) report compression ratio via nodetool cfstats