git commit: Fix license

2013-10-24 Thread slebresne
Updated Branches:
  refs/heads/cassandra-2.0 a2b224a45 - 22e67be8f


Fix license


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

Branch: refs/heads/cassandra-2.0
Commit: 22e67be8fec2132c6480a63d3b99946a4fabb3a5
Parents: a2b224a
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Oct 24 09:15:58 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Oct 24 09:15:58 2013 +0200

--
 bin/cqlsh.bat| 18 +-
 debian/changelog |  2 +-
 2 files changed, 18 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/22e67be8/bin/cqlsh.bat
--
diff --git a/bin/cqlsh.bat b/bin/cqlsh.bat
index e54aebf..36023ea 100644
--- a/bin/cqlsh.bat
+++ b/bin/cqlsh.bat
@@ -1,5 +1,21 @@
+@REM
+@REM Licensed to the Apache Software Foundation (ASF) under one or more
+@REM contributor license agreements. See the NOTICE file distributed with
+@REM this work for additional information regarding copyright ownership.
+@REM The ASF licenses this file to You under the Apache License, Version 2.0
+@REM (the License); you may not use this file except in compliance with
+@REM the License. You may obtain a copy of the License at
+@REM
+@REM http://www.apache.org/licenses/LICENSE-2.0
+@REM
+@REM Unless required by applicable law or agreed to in writing, software
+@REM distributed under the License is distributed on an AS IS BASIS,
+@REM WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+@REM See the License for the specific language governing permissions and
+@REM limitations under the License.
+
 @echo off
 
 set DSDIR=%~dp0..
 
-%DSDIR%\python\python.exe %DSDIR%\apache-cassandra\bin\cqlsh %*
\ No newline at end of file
+%DSDIR%\python\python.exe %DSDIR%\apache-cassandra\bin\cqlsh %*

http://git-wip-us.apache.org/repos/asf/cassandra/blob/22e67be8/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 4d99120..f27c0e1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,7 +2,7 @@ cassandra (2.0.2) unstable; urgency=low
 
   * New release
 
- -- Sylvain Lebresne slebre...@apache.org  Tue, 22 Oct 2013 17:44:30 +0200
+ -- Sylvain Lebresne slebre...@apache.org  Thu, 24 Oct 2013 09:15:30 +0200
 
 cassandra (2.0.1) unstable; urgency=low
 



Git Push Summary

2013-10-24 Thread slebresne
Updated Tags:  refs/tags/2.0.2-tentative [deleted] b6147c1c7


Git Push Summary

2013-10-24 Thread slebresne
Updated Tags:  refs/tags/2.0.2-tentative [created] 22e67be8f


[Cassandra Wiki] Update of RunningCassandraInIDEA by JonathanEllis

2013-10-24 Thread Apache Wiki
Dear Wiki user,

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

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

  IDEA is now open source!  The free community edition at 
http://www.jetbrains.org is all you need for Cassandra development.  (You don't 
need J2EE or Web tools.)
+ 
+ You can create an IntelliJ project in just two steps:
+ 
+  1. Run ant generate-eclipse-files
+  1. File - Import Project
+ 
+ If you want to get up close and personal with setting it up manually instead 
of cheating like that, read on...
  
  TableOfContents
  
  = Setup Cassandra as a project =
+ Preconditions: JDK6 and Ant (http://ant.apache.org/)
  
- Preconditions: JDK6 and Ant (http://ant.apache.org/) 
+ IDEA will generally set the project up properly for you (you'll need to run 
some ant targets and add a couple of folders as content roots).
  
+ Open IDEA and Select Check out from Version Control under Quick Start and 
select 'Git' or 'Subversion' (this tutorial will use Git). (The URL to the 
Apache Cassandra svn is https://svn.apache.org/repos/asf/cassandra/trunk, the 
'Git Repository URL' is git://git.apache.org/cassandra.git)
- IDEA will generally set the project up properly for you (you'll need to run 
some ant targets and add a couple of folders as content roots). 
- 
- Open IDEA and Select Check out from Version Control under Quick Start and 
select 'Git' or 'Subversion' (this tutorial will use Git).
- (The URL to the Apache Cassandra svn is 
https://svn.apache.org/repos/asf/cassandra/trunk, the 'Git Repository URL' is 
git://git.apache.org/cassandra.git)
-  
  
  {{attachment:CheckOutFromVersionControl-1.png}}
  
+ Parent directory is where IDEA will place the Cassandra checkout/clone. Press 
Clone to engage the checkout/clone (be patient, will take some time).  Answer 
'Yes' to Would you like to create an IntelliJ IDEA project for the sources you 
have checked out to /Users/schildmeijer/workspace/cassandra?
- Parent directory is where IDEA will place the Cassandra checkout/clone.
- Press Clone to engage the checkout/clone (be patient, will take some time). 
- Answer 'Yes' to Would you like to create an IntelliJ IDEA project for the 
sources you have checked out to /Users/schildmeijer/workspace/cassandra?
  
  {{attachment:CloneRepository-2.png}}
  
@@ -26, +28 @@

  
  {{attachment:CreateProjectFromExistingSources-3.png}}
  
+ Pick an appropriate name for the new project (e.g cassandra) 'Project files 
location' is where on the file system IDEA will create your Java project.
- Pick an appropriate name for the new project (e.g cassandra)
- 'Project files location' is where on the file system IDEA will create your 
Java project.
  
  {{attachment:NewProject-4.png}}
  
  Add the following Java source files to your module.
+ 
-   * interface/thrift/gen-java
+  * interface/thrift/gen-java
-   * src/java
+  * src/java
-   * test/unit
+  * test/unit
  
  {{attachment:NewProjectChooseModules-5.png}}
  
  Press 'Next' followed by 'Finish' after you have reviewed the suggested 
module structure. I recommend to only have one module (Cassandra).
  
+ {{attachment:NewProjectReviewLibrariesFound-6.png}} 
{{attachment:NewProjectReviewModuleStructure-7.png}}
- {{attachment:NewProjectReviewLibrariesFound-6.png}}
- {{attachment:NewProjectReviewModuleStructure-7.png}}
  
  Your project will be now imported into the IDEA project workspace. Wait until 
the project indexing is done. (This might take some time depending on your 
computer)
  
  Your IDEA project workspace should now look something like this:
  
  {{attachment:InitialProjectWorkspace-8.png}}
-  
+ 
- Whats left now is to generate the Command Line Interface (CLI) grammar by 
ANTLR, add the conf folder to your sources, so that log4j properties can be 
found, generate the avro code and finally add these folders as content roots. 
+ Whats left now is to generate the Command Line Interface (CLI) grammar by 
ANTLR, add the conf folder to your sources, so that log4j properties can be 
found, generate the avro code and finally add these folders as content roots.
  
  First we will generate some code (CLI grammar, avro bindings, thrift 
bindings). This is where ant enters the building.
  
+ Press the 'Ant Build' tab (far to the right), then 'Add' (the plus sign) and 
locate the build.xml in your cassandra project folder. Run the ant 'build' 
target by double clicking on it (this should hopefully generate all the code 
necessary to run cassandra in IDEA). (Press no if IDEA asks you to add some 
project specific files to git/svn version control).
- Press the 'Ant Build' tab (far to the right), then 'Add' (the plus sign) and 
locate the build.xml in your cassandra project folder.
- Run the ant 'build' target by double clicking on it (this should hopefully 
generate all the code necessary to run cassandra in IDEA).
- (Press no if 

[jira] [Created] (CASSANDRA-6235) Improve native protocol server latency

2013-10-24 Thread Sylvain Lebresne (JIRA)
Sylvain Lebresne created CASSANDRA-6235:
---

 Summary: Improve native protocol server latency
 Key: CASSANDRA-6235
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6235
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne


The tl;dr is that the native protocol server seems to add some non negligeable 
latency to operations compared to the thrift server. And the added latency 
seems to lie within Netty's internal as far as I can tell. I'm not sure what to 
tweak to try to reduce that.

The test I ran is simple: it's {{stress -t 1 -L3}}, the Cassandra stress test 
for insertions with just 1 thread and using CQL-over-thrift (to make things 
more comparable). What I'm interested in is the average latency. Also, because 
I don't care about testing the storage engine or even CQL processing, I've 
disabled the processing of statements: all queries just return an empty result 
set right away (there's no parsing of the query in particular). The resulting 
branch is at https://github.com/pcmanus/cassandra/commits/latency-testing (note 
that there's a trivial patch to have stress show the latency in microseconds).

With that branch (single node), I get with thrift ~62μs of average latency. 
That number is actually fairly stable across runs (not doing any real 
processing helps having consistent performance here).

For the native protocol, I wanted to eliminate the possibility that the 
DataStax Java driver was the bottleneck so I wrote a very simple class 
(NPTester.java, attached) that emulates the stress test above but with the 
native protocol. It's not execssively pretty but its simple (no dependencies, 
compiles with javac NPTester.java) and it tries to minimize the client side 
overhead. It's just a basic loop that write query frames (serializing them 
largely manually) and read the result back. And it measures the latency as 
close to the socket as possible. Unless I've done something really wrong, it 
should have less client side overhead than what stress has.

With that tester, the average latency I get is ~140μs. This is more than twice 
that of thrift.

To try to understand where that additional latency was spent, I instrumented 
the Frame coder/decoder to record latencies (last commit of the latency-test 
branch above): it records how long it takes to decode, execute and re-encode 
the query. The latency for that is ~35μs (as other numbers above, this is 
pretty consistent over runs). Given that my ping on localhost is 30μs, this 
suggest that compared to thrift, Netty spends ~70μs more than the thrift server 
somewhere while reading and/or writing data on the wire. I've try yourkitting 
it but I didn't saw anything obvious so I'm not sure what's the problem, but it 
sure would be nice to get on par (or at least much closer) with thrift on such 
a simple test.

I'll note that if I run the same tests without disabling actual query 
processing, the tests have a bit more variability, but for thrift I get 
~220-230μs latency on average while the NPTester gets ~290-300μs. In other 
words, there still seems to be that 70μs overhead for the native protocol. 
Which in that case is still a 30% slowdown. I'll also note that test 
comparisons with more threads (using the java driver this time) also show the 
native protocol being slightly slower than thrift (~5-10% slower), and while 
there might be inefficiencies in the java driver, I'm growing more and more 
convinced that at least part of it is due to the latency issue described 
above.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (CASSANDRA-6235) Improve native protocol server latency

2013-10-24 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-6235:


Attachment: NPTester.java

 Improve native protocol server latency
 --

 Key: CASSANDRA-6235
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6235
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
 Attachments: NPTester.java


 The tl;dr is that the native protocol server seems to add some non 
 negligeable latency to operations compared to the thrift server. And the 
 added latency seems to lie within Netty's internal as far as I can tell. I'm 
 not sure what to tweak to try to reduce that.
 The test I ran is simple: it's {{stress -t 1 -L3}}, the Cassandra stress test 
 for insertions with just 1 thread and using CQL-over-thrift (to make things 
 more comparable). What I'm interested in is the average latency. Also, 
 because I don't care about testing the storage engine or even CQL processing, 
 I've disabled the processing of statements: all queries just return an empty 
 result set right away (there's no parsing of the query in particular). The 
 resulting branch is at 
 https://github.com/pcmanus/cassandra/commits/latency-testing (note that 
 there's a trivial patch to have stress show the latency in microseconds).
 With that branch (single node), I get with thrift ~62μs of average latency. 
 That number is actually fairly stable across runs (not doing any real 
 processing helps having consistent performance here).
 For the native protocol, I wanted to eliminate the possibility that the 
 DataStax Java driver was the bottleneck so I wrote a very simple class 
 (NPTester.java, attached) that emulates the stress test above but with the 
 native protocol. It's not execssively pretty but its simple (no dependencies, 
 compiles with javac NPTester.java) and it tries to minimize the client side 
 overhead. It's just a basic loop that write query frames (serializing them 
 largely manually) and read the result back. And it measures the latency as 
 close to the socket as possible. Unless I've done something really wrong, it 
 should have less client side overhead than what stress has.
 With that tester, the average latency I get is ~140μs. This is more than 
 twice that of thrift.
 To try to understand where that additional latency was spent, I 
 instrumented the Frame coder/decoder to record latencies (last commit of 
 the latency-test branch above): it records how long it takes to decode, 
 execute and re-encode the query. The latency for that is ~35μs (as other 
 numbers above, this is pretty consistent over runs). Given that my ping on 
 localhost is 30μs, this suggest that compared to thrift, Netty spends ~70μs 
 more than the thrift server somewhere while reading and/or writing data on 
 the wire. I've try yourkitting it but I didn't saw anything obvious so I'm 
 not sure what's the problem, but it sure would be nice to get on par (or at 
 least much closer) with thrift on such a simple test.
 I'll note that if I run the same tests without disabling actual query 
 processing, the tests have a bit more variability, but for thrift I get 
 ~220-230μs latency on average while the NPTester gets ~290-300μs. In other 
 words, there still seems to be that 70μs overhead for the native protocol. 
 Which in that case is still a 30% slowdown. I'll also note that test 
 comparisons with more threads (using the java driver this time) also show the 
 native protocol being slightly slower than thrift (~5-10% slower), and while 
 there might be inefficiencies in the java driver, I'm growing more and more 
 convinced that at least part of it is due to the latency issue described 
 above.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CASSANDRA-6236) Update native protocol server to Netty 4

2013-10-24 Thread Sylvain Lebresne (JIRA)
Sylvain Lebresne created CASSANDRA-6236:
---

 Summary: Update native protocol server to Netty 4
 Key: CASSANDRA-6236
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6236
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Priority: Minor
 Fix For: 2.1


We should switch to Netty 4 at some point, since it's the future.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CASSANDRA-6237) Allow range deletions in CQL

2013-10-24 Thread Sylvain Lebresne (JIRA)
Sylvain Lebresne created CASSANDRA-6237:
---

 Summary: Allow range deletions in CQL
 Key: CASSANDRA-6237
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6237
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Priority: Minor


We uses RangeTombstones internally in a number of places, but we could expose 
more directly too. Typically, given a table like:
{noformat}
CREATE TABLE events (
id text,
created_at timestamp,
content text,
PRIMARY KEY (id, created_at)
)
{noformat}
we could allow queries like:
{noformat}
DELETE FROM events WHERE id='someEvent' AND created_at  'Jan 3, 2013';
{noformat}



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6235) Improve native protocol server latency

2013-10-24 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-6235:
---

Might be another place to get some input from [~norman].

 Improve native protocol server latency
 --

 Key: CASSANDRA-6235
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6235
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
 Attachments: NPTester.java


 The tl;dr is that the native protocol server seems to add some non 
 negligeable latency to operations compared to the thrift server. And the 
 added latency seems to lie within Netty's internal as far as I can tell. I'm 
 not sure what to tweak to try to reduce that.
 The test I ran is simple: it's {{stress -t 1 -L3}}, the Cassandra stress test 
 for insertions with just 1 thread and using CQL-over-thrift (to make things 
 more comparable). What I'm interested in is the average latency. Also, 
 because I don't care about testing the storage engine or even CQL processing, 
 I've disabled the processing of statements: all queries just return an empty 
 result set right away (there's no parsing of the query in particular). The 
 resulting branch is at 
 https://github.com/pcmanus/cassandra/commits/latency-testing (note that 
 there's a trivial patch to have stress show the latency in microseconds).
 With that branch (single node), I get with thrift ~62μs of average latency. 
 That number is actually fairly stable across runs (not doing any real 
 processing helps having consistent performance here).
 For the native protocol, I wanted to eliminate the possibility that the 
 DataStax Java driver was the bottleneck so I wrote a very simple class 
 (NPTester.java, attached) that emulates the stress test above but with the 
 native protocol. It's not execssively pretty but its simple (no dependencies, 
 compiles with javac NPTester.java) and it tries to minimize the client side 
 overhead. It's just a basic loop that write query frames (serializing them 
 largely manually) and read the result back. And it measures the latency as 
 close to the socket as possible. Unless I've done something really wrong, it 
 should have less client side overhead than what stress has.
 With that tester, the average latency I get is ~140μs. This is more than 
 twice that of thrift.
 To try to understand where that additional latency was spent, I 
 instrumented the Frame coder/decoder to record latencies (last commit of 
 the latency-test branch above): it records how long it takes to decode, 
 execute and re-encode the query. The latency for that is ~35μs (as other 
 numbers above, this is pretty consistent over runs). Given that my ping on 
 localhost is 30μs, this suggest that compared to thrift, Netty spends ~70μs 
 more than the thrift server somewhere while reading and/or writing data on 
 the wire. I've try yourkitting it but I didn't saw anything obvious so I'm 
 not sure what's the problem, but it sure would be nice to get on par (or at 
 least much closer) with thrift on such a simple test.
 I'll note that if I run the same tests without disabling actual query 
 processing, the tests have a bit more variability, but for thrift I get 
 ~220-230μs latency on average while the NPTester gets ~290-300μs. In other 
 words, there still seems to be that 70μs overhead for the native protocol. 
 Which in that case is still a 30% slowdown. I'll also note that test 
 comparisons with more threads (using the java driver this time) also show the 
 native protocol being slightly slower than thrift (~5-10% slower), and while 
 there might be inefficiencies in the java driver, I'm growing more and more 
 convinced that at least part of it is due to the latency issue described 
 above.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[4/7] git commit: Don't NPE when shutting down non-existent thrift server

2013-10-24 Thread brandonwilliams
Don't NPE when shutting down non-existent thrift server


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

Branch: refs/heads/cassandra-2.0
Commit: 9eddaa8ffa212c42f32f7d1e8b485d5aa0e2f10f
Parents: c040759
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 24 09:56:38 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 24 09:56:38 2013 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9eddaa8f/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index bde54a7..96c2dd9 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -318,7 +318,8 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 {
 throw new IllegalStateException(No configured daemon);
 }
-daemon.thriftServer.stop();
+if (daemon.thriftServer != null)
+daemon.thriftServer.stop();
 }
 
 public boolean isRPCServerRunning()



[1/7] git commit: Fix license

2013-10-24 Thread brandonwilliams
Updated Branches:
  refs/heads/cassandra-1.2 c040759da - 9eddaa8ff
  refs/heads/cassandra-2.0 22e67be8f - 21e6ec6d8
  refs/heads/trunk 8664e3aa5 - fb7e0b1c2


Fix license


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

Branch: refs/heads/trunk
Commit: 22e67be8fec2132c6480a63d3b99946a4fabb3a5
Parents: a2b224a
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Oct 24 09:15:58 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Oct 24 09:15:58 2013 +0200

--
 bin/cqlsh.bat| 18 +-
 debian/changelog |  2 +-
 2 files changed, 18 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/22e67be8/bin/cqlsh.bat
--
diff --git a/bin/cqlsh.bat b/bin/cqlsh.bat
index e54aebf..36023ea 100644
--- a/bin/cqlsh.bat
+++ b/bin/cqlsh.bat
@@ -1,5 +1,21 @@
+@REM
+@REM Licensed to the Apache Software Foundation (ASF) under one or more
+@REM contributor license agreements. See the NOTICE file distributed with
+@REM this work for additional information regarding copyright ownership.
+@REM The ASF licenses this file to You under the Apache License, Version 2.0
+@REM (the License); you may not use this file except in compliance with
+@REM the License. You may obtain a copy of the License at
+@REM
+@REM http://www.apache.org/licenses/LICENSE-2.0
+@REM
+@REM Unless required by applicable law or agreed to in writing, software
+@REM distributed under the License is distributed on an AS IS BASIS,
+@REM WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+@REM See the License for the specific language governing permissions and
+@REM limitations under the License.
+
 @echo off
 
 set DSDIR=%~dp0..
 
-%DSDIR%\python\python.exe %DSDIR%\apache-cassandra\bin\cqlsh %*
\ No newline at end of file
+%DSDIR%\python\python.exe %DSDIR%\apache-cassandra\bin\cqlsh %*

http://git-wip-us.apache.org/repos/asf/cassandra/blob/22e67be8/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 4d99120..f27c0e1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,7 +2,7 @@ cassandra (2.0.2) unstable; urgency=low
 
   * New release
 
- -- Sylvain Lebresne slebre...@apache.org  Tue, 22 Oct 2013 17:44:30 +0200
+ -- Sylvain Lebresne slebre...@apache.org  Thu, 24 Oct 2013 09:15:30 +0200
 
 cassandra (2.0.1) unstable; urgency=low
 



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

2013-10-24 Thread brandonwilliams
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/fb7e0b1c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fb7e0b1c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fb7e0b1c

Branch: refs/heads/trunk
Commit: fb7e0b1c23e594abf00a8a243b44134a8f3d2c96
Parents: 8664e3a 21e6ec6
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 24 09:57:12 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 24 09:57:12 2013 -0500

--
 bin/cqlsh.bat | 18 +-
 debian/changelog  |  2 +-
 .../apache/cassandra/service/StorageService.java  |  3 ++-
 3 files changed, 20 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb7e0b1c/src/java/org/apache/cassandra/service/StorageService.java
--



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

2013-10-24 Thread brandonwilliams
Merge branch 'cassandra-1.2' into cassandra-2.0


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

Branch: refs/heads/trunk
Commit: 21e6ec6d81b76be762199f59650f97876133544f
Parents: 22e67be 9eddaa8
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 24 09:56:58 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 24 09:56:58 2013 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/21e6ec6d/src/java/org/apache/cassandra/service/StorageService.java
--



[3/7] git commit: Don't NPE when shutting down non-existent thrift server

2013-10-24 Thread brandonwilliams
Don't NPE when shutting down non-existent thrift server


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

Branch: refs/heads/trunk
Commit: 9eddaa8ffa212c42f32f7d1e8b485d5aa0e2f10f
Parents: c040759
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 24 09:56:38 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 24 09:56:38 2013 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9eddaa8f/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index bde54a7..96c2dd9 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -318,7 +318,8 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 {
 throw new IllegalStateException(No configured daemon);
 }
-daemon.thriftServer.stop();
+if (daemon.thriftServer != null)
+daemon.thriftServer.stop();
 }
 
 public boolean isRPCServerRunning()



[2/7] git commit: Don't NPE when shutting down non-existent thrift server

2013-10-24 Thread brandonwilliams
Don't NPE when shutting down non-existent thrift server


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

Branch: refs/heads/cassandra-1.2
Commit: 9eddaa8ffa212c42f32f7d1e8b485d5aa0e2f10f
Parents: c040759
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 24 09:56:38 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 24 09:56:38 2013 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9eddaa8f/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index bde54a7..96c2dd9 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -318,7 +318,8 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 {
 throw new IllegalStateException(No configured daemon);
 }
-daemon.thriftServer.stop();
+if (daemon.thriftServer != null)
+daemon.thriftServer.stop();
 }
 
 public boolean isRPCServerRunning()



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

2013-10-24 Thread brandonwilliams
Merge branch 'cassandra-1.2' into cassandra-2.0


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

Branch: refs/heads/cassandra-2.0
Commit: 21e6ec6d81b76be762199f59650f97876133544f
Parents: 22e67be 9eddaa8
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 24 09:56:58 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 24 09:56:58 2013 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/21e6ec6d/src/java/org/apache/cassandra/service/StorageService.java
--



[jira] [Resolved] (CASSANDRA-2864) Alternative Row Cache Implementation

2013-10-24 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne resolved CASSANDRA-2864.
-

Resolution: Won't Fix

There is definitively good idea in there and I apologize for having it dropped 
from my radar. However, I think we've decided that we wanted to move the row 
cache to a query cache (CASSANDRA-5357) so I think this supersedes that ticket. 
That being said, we certainly should consider some of the ideas here when we 
work on said query cache and I'll add a comment to that effect on 
CASSANDRA-5357.

 Alternative Row Cache Implementation
 

 Key: CASSANDRA-2864
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2864
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Daniel Doubleday
Assignee: Daniel Doubleday
  Labels: cache
 Fix For: 2.1

 Attachments: 0001-CASSANDRA-2864-w-out-direct-counter-support.patch, 
 optimistic-locking.patch, rowcache-with-snaptree-sketch.patch


 we have been working on an alternative implementation to the existing row 
 cache(s)
 We have 2 main goals:
 - Decrease memory - get more rows in the cache without suffering a huge 
 performance penalty
 - Reduce gc pressure
 This sounds a lot like we should be using the new serializing cache in 0.8. 
 Unfortunately our workload consists of loads of updates which would 
 invalidate the cache all the time.
 *Note: Updated Patch Description (Please check history if you're interested 
 where this was comming from)*
 h3. Rough Idea
 - Keep serialized row (ByteBuffer) in mem which represents unfiltered but 
 collated columns of all ssts but not memtable columns
 - Writes dont affect the cache at all. They go only to the memtables
 - Reads collect columns from memtables and row cache
 - Serialized Row is re-written (merged) with mem tables when flushed
 h3. Some Implementation Details
 h4. Reads
 - Basically the read logic differ from regular uncached reads only in that a 
 special CollationController which is deserializing columns from in memory 
 bytes
 - In the first version of this cache the serialized in memory format was the 
 same as the fs format but test showed that performance sufferd because a lot 
 of unnecessary deserialization takes place and that columns seeks are O( n ) 
 whithin one block
 - To improve on that a different in memory format was used. It splits length 
 meta info and data of columns so that the names can be binary searched. 
 {noformat}
 ===
 Header (24)
 ===
 MaxTimestamp:long  
 LocalDeletionTime:   int   
 MarkedForDeleteAt:   long  
 NumColumns:  int   
 ===
 Column Index (num cols * 12)  
 ===
 NameOffset:  int   
 ValueOffset: int   
 ValueLength: int   
 ===
 Column Data
 ===
 Name:byte[]
 Value:   byte[]
 SerializationFlags:  byte  
 Misc:? 
 Timestamp:   long  
 ---
 Misc Counter Column
 ---
 TSOfLastDelete:  long  
 ---
 Misc Expiring Column   
 ---
 TimeToLive:  int   
 LocalDeletionTime:   int   
 ===
 {noformat}
 - These rows are read by 2 new column interators which correspond to 
 SSTableNamesIterator and SSTableSliceIterator. During filtering only columns 
 that actually match are constructed. The searching / skipping is performed on 
 the raw ByteBuffer and does not create any objects.
 - A special CollationController is used to access and collate via cache and 
 said new iterators. It also supports skipping the cached row by max update 
 timestamp
 h4. Writes
 - Writes dont update or invalidate the cache.
 - In CFS.replaceFlushed memtables are merged before the data view is 
 switched. I fear that this is killing counters because they would be 
 overcounted but my understading of counters is somewhere between weak and 
 non-existing. I guess that counters if one wants to support them here would 
 need an additional unique local identifier in memory and in serialized cache 
 to be able to filter duplicates or something like that.
 {noformat}
 void replaceFlushed(Memtable memtable, SSTableReader sstable)
 {
 if (sstCache.getCapacity()  0) {
 mergeSSTCache(memtable);
 }
 data.replaceFlushed(memtable, sstable);
 CompactionManager.instance.submitBackground(this);
 }
 {noformat}
 Test Results: See comments below



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-5357) Query cache

2013-10-24 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-5357:
-

Having really followed the progress here so I don't know how much relevant that 
is, but while we switch to a query cache, we should probably have a look at the 
ideas from CASSANDRA-2864. Some of them possibly apply here too.

 Query cache
 ---

 Key: CASSANDRA-5357
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5357
 Project: Cassandra
  Issue Type: Bug
Reporter: Jonathan Ellis
Assignee: Vijay

 I think that most people expect the row cache to act like a query cache, 
 because that's a reasonable model.  Caching the entire partition is, in 
 retrospect, not really reasonable, so it's not surprising that it catches 
 people off guard, especially given the confusion we've inflicted on ourselves 
 as to what a row constitutes.
 I propose replacing it with a true query cache.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6127) vnodes don't scale to hundreds of nodes

2013-10-24 Thread Quentin Conner (JIRA)

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

Quentin Conner commented on CASSANDRA-6127:
---

*Background and Reproduction*

The symptom is evident with the presence of is now DOWN messages in the 
Cassandra system.log file.  The recording of a node DOWN is often followed by a 
node UP a few seconds later.  Users have coined this phenomenon gossip flap 
and the occurence of Gossip flaps has a machine and a human consequence.

Humans react strongly to the (temporary) marking of a node down.  Automated 
monitoring may trigger SNMP traps, etc.  A busy node that doesn't transmit 
heartbeat gossip messages on time will be marked as down though it may still 
be performing useful work.

Machine reactions include other C* nodes buffering of row mutations and storage 
of hints on disk when another node is marked down.  I have not explored the 
machine reactions but imagine the endpointSnitch could also be affected from 
the client frame of reference.

One piece of good news is that I was able to reproduce two different use cases 
that elicit the is now DOWN message in Log4J log files.

Use Case #1 is as follows:
  provision 256 or 512 nodes in EC2
  install Cassandra 1.2.9
  take defaults except specify num_tokens=256 in c*.yaml
  start one node at a time

Use Case #2 is as follows:
  provision 32 nodes in EC2
  install Cassandra 1.2.9
  take defaults in c*.yaml
  configure rack
  start one node at a time
  when all nodes are up create about 1GB of data
e.g. tools/bin/cassandra-stress -c 20 -l 3 -n 100
  provision a 33rdxtra node in EC2
  install Cassandra 1.2.9
  take defaults except specify num_tokens=256
  start the node (auto_bootstrap=true)




 vnodes don't scale to hundreds of nodes
 ---

 Key: CASSANDRA-6127
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6127
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Any cluster that has vnodes and consists of hundreds of 
 physical nodes.
Reporter: Tupshin Harper
Assignee: Jonathan Ellis

 There are a lot of gossip-related issues related to very wide clusters that 
 also have vnodes enabled. Let's use this ticket as a master in case there are 
 sub-tickets.
 The most obvious symptom I've seen is with 1000 nodes in EC2 with m1.xlarge 
 instances. Each node configured with 32 vnodes.
 Without vnodes, cluster spins up fine and is ready to handle requests within 
 30 minutes or less. 
 With vnodes, nodes are reporting constant up/down flapping messages with no 
 external load on the cluster. After a couple of hours, they were still 
 flapping, had very high cpu load, and the cluster never looked like it was 
 going to stabilize or be useful for traffic.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6127) vnodes don't scale to hundreds of nodes

2013-10-24 Thread Quentin Conner (JIRA)

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

Quentin Conner commented on CASSANDRA-6127:
---

*Feature Suggestion*

The current Gossip failure detector is characterized by a sliding window of 
elapsed time, a heartbeat message period and a PHI threshold used to make the 
continuous random variable (lower case phi) into a dichotomous (binary) random 
variable.  That PHI (uppercase) threshold is called phi_convict_threshold.

I don't have a better mathmatical theory or derivation at this writing, but I 
do have an easy workaround for your consideration.  While phi_convict_threshold 
is adjustable, the period (or frequency) of Gossip messages is not.  Adjusting 
the gossip period to integrate over a longer time baseline reduced false 
positives from the Gossip failure detector.  The side effect increases the 
elapsed time to detect a legitimately-failed node.

Depending on user workload characteristics, and the related sources of latency 
(CPU, disk and network activity or transient delays) cited above, a System 
Architect could present a reasonable use case for controlling the Gossip 
message period.

The goal would be to set a detection window that accomodates common occurences 
for a given deployment scenario.  Not all data centers are created equal.

Patches and results from implementation will follow in subsequent posts.

*Potential Next Steps*
  Explore concern about sensitivity to gossip period.  Do the vnode gossip 
messages exceed capacity for peers to ingest?
  Explore concern about phi estimates from un-filled (new) deque.
  Explore concern about assuming Gaussian PDF.  Networks (not computers) 
generally characterize expected arrival time by Poisson distribution, not 
Gaussian.


 vnodes don't scale to hundreds of nodes
 ---

 Key: CASSANDRA-6127
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6127
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Any cluster that has vnodes and consists of hundreds of 
 physical nodes.
Reporter: Tupshin Harper
Assignee: Jonathan Ellis

 There are a lot of gossip-related issues related to very wide clusters that 
 also have vnodes enabled. Let's use this ticket as a master in case there are 
 sub-tickets.
 The most obvious symptom I've seen is with 1000 nodes in EC2 with m1.xlarge 
 instances. Each node configured with 32 vnodes.
 Without vnodes, cluster spins up fine and is ready to handle requests within 
 30 minutes or less. 
 With vnodes, nodes are reporting constant up/down flapping messages with no 
 external load on the cluster. After a couple of hours, they were still 
 flapping, had very high cpu load, and the cluster never looked like it was 
 going to stabilize or be useful for traffic.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6127) vnodes don't scale to hundreds of nodes

2013-10-24 Thread Quentin Conner (JIRA)

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

Quentin Conner commented on CASSANDRA-6127:
---

*Analysis*

My first experiments aimed to quantify the length of Gossip messages and 
determine what factors drive the message length.  I found the size of certain 
gossip messages increases proportionally with the number of vnodes (num_tokens 
in c.yaml).  I recorded message size over the num_tokens and number of nodes 
domains (64,128,256,512,...) for tokens and (32,64,128,256,512) for nodes.  I 
also made non-rigorous observation of User and Kernel CPU (Ubuntu 10.0.4 LTS).  
My hunch is that both vnode count and node count have a mild effect on user CPU 
resource usage.

What is the rough estimate of bytes sent for certain Gossip messages and why 
does this matter?  The Phi Accrual Failure Detector (Hayashibara, et al) 
assumes fixed length heartbeat messages while Cassandra uses variable length 
messages.  I observed a correlation with larger messages, higher vnodes and 
false positive detections by the Gossip FailureDetector.  These observations, 
IMHO, are not explained by the research paper.  I formed a hypothesis that the 
false positives are due to jitter in the interval values.  I wondered if 
perhaps using a longer baseline to integrate over would reduce the jitter.  

I have a second theory to follow up on.  A newly added node will not have a 
long history of Gossip heartbeat interarrival times.  At least 40 samples are 
needed to compute mean, variance with any statistical significance.  It's 
possible the phi estimation algorithm is simply invalid for newly created nodes 
and that is why we see them flap shortly after creation.

In any case, the message of interest is the GossipDigestAck2 (GDA2) because it 
is the largest of the Gossip messages.  GDA2 contains the set of 
EndpointStateMaps (node metadata) for newly-discovered nodes, i.e. those nodes 
just added to an existing cluster.  When each node becomes aware of joining 
node, they Gossip it to three randomly-chosen other nodes.  The GDA2 message is 
tailored to contain the delta of new node metadata the receiving node is 
unaware of.

For a single node, the upper limit on GDA message size is roughly 3 * N * k * V
Where N is the number of nodes in the cluster,
V is the number of tokens (vnodes) per cluster,
k is a constant value, approximately 64 bytes, that represents a serialized 
token plus some other endpoint metadata.

If one is running hundreds of nodes in a cluster, the Gossip message traffic 
created when a node joins can be significant and increases with the number of 
nodes.  I believe this to be the first order effect and probably violates one 
of the assumptions of the PHI Accrual Failure Detection, that heartbeat 
messages are small enough not to consume a relevant amount of compute or 
communication resources.  The variable transmission time (due to variable 
length messages) is a clear violation of assumptions, if I've read the source 
code correctly.

On a related topic, there is a hard-coded limitation to the number of vnodes 
due to the serialization of the GDA messages.
No more than 1720 vnodes can be configured without creating a greater than 32K 
serialized String vnode message.  A patch is provided below for future use 
should this become an issue.

In clusters with hundreds of nodes, GDA2 messages can be 200 KB or 2 MB if many 
nodes join simultaneously.  This is not an issue if the computer experiences no 
latency from competing workloads.  In the real world, nodes are added because 
the cluster load has grown in terms of retained data, or in terms of a high 
transaction arrival rate.  This means node resources may be fully utilized when 
adding new nodes is typically attempted.

It occured to me that we have another use case to accomodate.  It is common to 
experience transient failure modes, even in modern data centers with 
disciplined maintenance practices.  Ethernet cables get moved, switches and 
routers rebooted.  BGP route errors and other temporary interruptions may occur 
with the network fabric in real world scenarios.  People make mistakes, plans 
change and preventative maintenance often causes short-lived interruptions 
occur with network, CPU and disk subsystems.


 vnodes don't scale to hundreds of nodes
 ---

 Key: CASSANDRA-6127
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6127
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Any cluster that has vnodes and consists of hundreds of 
 physical nodes.
Reporter: Tupshin Harper
Assignee: Jonathan Ellis

 There are a lot of gossip-related issues related to very wide clusters that 
 also have vnodes enabled. Let's use this ticket as a 

[jira] [Updated] (CASSANDRA-6127) vnodes don't scale to hundreds of nodes

2013-10-24 Thread Quentin Conner (JIRA)

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

Quentin Conner updated CASSANDRA-6127:
--

Attachment: 6000vnodes.patch

Patch #1.  Increases number of allowed vnodes (num_tokens) from 1720 up to 
about 6000 with 512K stack size.

Because of CQL antlr grammar parser, stack is needed to parse token definitions.

 vnodes don't scale to hundreds of nodes
 ---

 Key: CASSANDRA-6127
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6127
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Any cluster that has vnodes and consists of hundreds of 
 physical nodes.
Reporter: Tupshin Harper
Assignee: Jonathan Ellis
 Attachments: 6000vnodes.patch


 There are a lot of gossip-related issues related to very wide clusters that 
 also have vnodes enabled. Let's use this ticket as a master in case there are 
 sub-tickets.
 The most obvious symptom I've seen is with 1000 nodes in EC2 with m1.xlarge 
 instances. Each node configured with 32 vnodes.
 Without vnodes, cluster spins up fine and is ready to handle requests within 
 30 minutes or less. 
 With vnodes, nodes are reporting constant up/down flapping messages with no 
 external load on the cluster. After a couple of hours, they were still 
 flapping, had very high cpu load, and the cluster never looked like it was 
 going to stabilize or be useful for traffic.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (CASSANDRA-6127) vnodes don't scale to hundreds of nodes

2013-10-24 Thread Quentin Conner (JIRA)

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

Quentin Conner updated CASSANDRA-6127:
--

Attachment: AdjustableGossipPeriod.patch

This is patch #2.  It adds a new configuration item in cassandra.yaml, 
gossip_period.  Set it in milliseconds.

Setting the gossip period by JMX will be lost if stop/restart gossip so needs 
more work.  Reading from JMX seems fine.

This also isn't DRY.  Should set the value for intervalInMillis, from config, 
in a static initializer.  Wasn't sure if config object is available in that 
scope.

 vnodes don't scale to hundreds of nodes
 ---

 Key: CASSANDRA-6127
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6127
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Any cluster that has vnodes and consists of hundreds of 
 physical nodes.
Reporter: Tupshin Harper
Assignee: Jonathan Ellis
 Attachments: 6000vnodes.patch, AdjustableGossipPeriod.patch


 There are a lot of gossip-related issues related to very wide clusters that 
 also have vnodes enabled. Let's use this ticket as a master in case there are 
 sub-tickets.
 The most obvious symptom I've seen is with 1000 nodes in EC2 with m1.xlarge 
 instances. Each node configured with 32 vnodes.
 Without vnodes, cluster spins up fine and is ready to handle requests within 
 30 minutes or less. 
 With vnodes, nodes are reporting constant up/down flapping messages with no 
 external load on the cluster. After a couple of hours, they were still 
 flapping, had very high cpu load, and the cluster never looked like it was 
 going to stabilize or be useful for traffic.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (CASSANDRA-6127) vnodes don't scale to hundreds of nodes

2013-10-24 Thread Quentin Conner (JIRA)

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

Quentin Conner updated CASSANDRA-6127:
--

Attachment: delayEstimatorUntilStatisticallyValid.patch

Untested patch #3.  Delays output from FailureDetector until statistically 
valid number of samples have been obtained.

 vnodes don't scale to hundreds of nodes
 ---

 Key: CASSANDRA-6127
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6127
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Any cluster that has vnodes and consists of hundreds of 
 physical nodes.
Reporter: Tupshin Harper
Assignee: Jonathan Ellis
 Attachments: 6000vnodes.patch, AdjustableGossipPeriod.patch, 
 delayEstimatorUntilStatisticallyValid.patch


 There are a lot of gossip-related issues related to very wide clusters that 
 also have vnodes enabled. Let's use this ticket as a master in case there are 
 sub-tickets.
 The most obvious symptom I've seen is with 1000 nodes in EC2 with m1.xlarge 
 instances. Each node configured with 32 vnodes.
 Without vnodes, cluster spins up fine and is ready to handle requests within 
 30 minutes or less. 
 With vnodes, nodes are reporting constant up/down flapping messages with no 
 external load on the cluster. After a couple of hours, they were still 
 flapping, had very high cpu load, and the cluster never looked like it was 
 going to stabilize or be useful for traffic.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6127) vnodes don't scale to hundreds of nodes

2013-10-24 Thread Quentin Conner (JIRA)

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

Quentin Conner commented on CASSANDRA-6127:
---

First results with workaround patch #2.
No load.  No data.  Only system keyspace and Gossip on a 256 node m1.medium 
cluster in EC2.
Nodes started in rapid succession.

*phi=8, variable gossip_period*
1154 flaps for 1 sec
685 flaps for 2 sec
146 flaps for 3 sec
88 flaps for 4 sec
70 flaps for 5 sec
100 flaps for 10 sec

*phi=12*
1289 flaps for 1 sec
77 flaps for 2 sec
6 flaps for 3 sec
1 flaps for 4 sec
3 flaps for 5 sec
1 flaps for 6 sec
0 flaps for 8 sec
1 flaps for 10 sec


 vnodes don't scale to hundreds of nodes
 ---

 Key: CASSANDRA-6127
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6127
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Any cluster that has vnodes and consists of hundreds of 
 physical nodes.
Reporter: Tupshin Harper
Assignee: Jonathan Ellis
 Attachments: 6000vnodes.patch, AdjustableGossipPeriod.patch, 
 delayEstimatorUntilStatisticallyValid.patch


 There are a lot of gossip-related issues related to very wide clusters that 
 also have vnodes enabled. Let's use this ticket as a master in case there are 
 sub-tickets.
 The most obvious symptom I've seen is with 1000 nodes in EC2 with m1.xlarge 
 instances. Each node configured with 32 vnodes.
 Without vnodes, cluster spins up fine and is ready to handle requests within 
 30 minutes or less. 
 With vnodes, nodes are reporting constant up/down flapping messages with no 
 external load on the cluster. After a couple of hours, they were still 
 flapping, had very high cpu load, and the cluster never looked like it was 
 going to stabilize or be useful for traffic.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Assigned] (CASSANDRA-6083) Pig requires explicit cast from int to long to save to Cassandra

2013-10-24 Thread Alex Liu (JIRA)

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

Alex Liu reassigned CASSANDRA-6083:
---

Assignee: Alex Liu

 Pig requires explicit cast from int to long to save to Cassandra
 

 Key: CASSANDRA-6083
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6083
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Chad Johnston
Assignee: Alex Liu
Priority: Minor

 Since version 1.2.10, I have to manually cast any int values in Pig to long 
 in order to store them into bigint Cassandra columns. I did not have to 
 perform this cast in previous versions of Cassandra.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Comment Edited] (CASSANDRA-6127) vnodes don't scale to hundreds of nodes

2013-10-24 Thread Quentin Conner (JIRA)

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

Quentin Conner edited comment on CASSANDRA-6127 at 10/24/13 6:26 PM:
-

*Background and Reproduction*

The symptom is evident with the presence of is now DOWN messages in the 
Cassandra system.log file.  The recording of a node DOWN is often followed by a 
node UP a few seconds later.  Users have coined this phenomenon gossip flap 
and the occurence of Gossip flaps has a machine and a human consequence.

Humans react strongly to the (temporary) marking of a node down.  Automated 
monitoring may trigger SNMP traps, etc.  A busy node that doesn't transmit 
heartbeat gossip messages on time will be marked as down though it may still 
be performing useful work.

Machine reactions include other C* nodes buffering of row mutations and storage 
of hints on disk when another node is marked down.  I have not explored the 
machine reactions but imagine the endpointSnitch could also be affected from 
the client frame of reference.

One piece of good news is that I was able to reproduce two different use cases 
that elicit the is now DOWN message in Log4J log files.

Use Case #1 is as follows:
  provision 256 or 512 nodes in EC2
  install Cassandra 1.2.9
  take defaults except specify num_tokens=256 in c*.yaml
  start one node at a time

Use Case #2 is as follows:
  provision 32 nodes in EC2
  install Cassandra 1.2.9
  take defaults in c*.yaml
  configure rack  datacenter
  start one node at a time
  when all nodes are up create about 1GB of data
e.g. tools/bin/cassandra-stress -c 20 -l 3 -n 100
  provision a 33rdxtra node in EC2
  install Cassandra 1.2.9
  take defaults except specify num_tokens=256
  configure different datacenter than first 32 nodes
  start the node (auto_bootstrap=true)





was (Author: qconner):
*Background and Reproduction*

The symptom is evident with the presence of is now DOWN messages in the 
Cassandra system.log file.  The recording of a node DOWN is often followed by a 
node UP a few seconds later.  Users have coined this phenomenon gossip flap 
and the occurence of Gossip flaps has a machine and a human consequence.

Humans react strongly to the (temporary) marking of a node down.  Automated 
monitoring may trigger SNMP traps, etc.  A busy node that doesn't transmit 
heartbeat gossip messages on time will be marked as down though it may still 
be performing useful work.

Machine reactions include other C* nodes buffering of row mutations and storage 
of hints on disk when another node is marked down.  I have not explored the 
machine reactions but imagine the endpointSnitch could also be affected from 
the client frame of reference.

One piece of good news is that I was able to reproduce two different use cases 
that elicit the is now DOWN message in Log4J log files.

Use Case #1 is as follows:
  provision 256 or 512 nodes in EC2
  install Cassandra 1.2.9
  take defaults except specify num_tokens=256 in c*.yaml
  start one node at a time

Use Case #2 is as follows:
  provision 32 nodes in EC2
  install Cassandra 1.2.9
  take defaults in c*.yaml
  configure rack
  start one node at a time
  when all nodes are up create about 1GB of data
e.g. tools/bin/cassandra-stress -c 20 -l 3 -n 100
  provision a 33rdxtra node in EC2
  install Cassandra 1.2.9
  take defaults except specify num_tokens=256
  start the node (auto_bootstrap=true)




 vnodes don't scale to hundreds of nodes
 ---

 Key: CASSANDRA-6127
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6127
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Any cluster that has vnodes and consists of hundreds of 
 physical nodes.
Reporter: Tupshin Harper
Assignee: Jonathan Ellis
 Attachments: 6000vnodes.patch, AdjustableGossipPeriod.patch, 
 delayEstimatorUntilStatisticallyValid.patch


 There are a lot of gossip-related issues related to very wide clusters that 
 also have vnodes enabled. Let's use this ticket as a master in case there are 
 sub-tickets.
 The most obvious symptom I've seen is with 1000 nodes in EC2 with m1.xlarge 
 instances. Each node configured with 32 vnodes.
 Without vnodes, cluster spins up fine and is ready to handle requests within 
 30 minutes or less. 
 With vnodes, nodes are reporting constant up/down flapping messages with no 
 external load on the cluster. After a couple of hours, they were still 
 flapping, had very high cpu load, and the cluster never looked like it was 
 going to stabilize or be useful for traffic.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Comment Edited] (CASSANDRA-6127) vnodes don't scale to hundreds of nodes

2013-10-24 Thread Quentin Conner (JIRA)

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

Quentin Conner edited comment on CASSANDRA-6127 at 10/24/13 6:28 PM:
-

*Feature Suggestion*

The current Gossip failure detector is characterized by a sliding window of 
elapsed time, a heartbeat message period and a PHI threshold used to make the 
continuous random variable (lower case phi) into a dichotomous (binary) random 
variable.  That PHI (uppercase) threshold is called phi_convict_threshold.

I don't have a better mathmatical theory or derivation at this writing, but I 
do have an easy workaround for your consideration.  While phi_convict_threshold 
is adjustable, the period (or frequency) of Gossip messages is not.  Adjusting 
the gossip period to integrate over a longer time baseline reduced false 
positives from the Gossip failure detector.  The side effect increases the 
elapsed time to detect a legitimately-failed node.

Depending on user workload characteristics, and the related sources of latency 
(CPU, disk and network activity or transient delays) cited above, a System 
Architect could present a reasonable use case for controlling the Gossip 
message period.

The goal would be to set a detection window that accomodates common occurences 
for a given deployment scenario.  Not all data centers are created equal.

Patches and results from implementation will follow in subsequent posts.

*Potential Next Steps*
  Explore concern about sensitivity to gossip period.  Do the vnode gossip 
messages exceed capacity for peers to ingest?
  Explore concern about phi estimates from un-filled (new) deque.  See Patch #3.
  Explore concern about assuming Gaussian PDF.  Networks (not computers) 
generally characterize expected arrival time by Poisson distribution, not 
Gaussian.



was (Author: qconner):
*Feature Suggestion*

The current Gossip failure detector is characterized by a sliding window of 
elapsed time, a heartbeat message period and a PHI threshold used to make the 
continuous random variable (lower case phi) into a dichotomous (binary) random 
variable.  That PHI (uppercase) threshold is called phi_convict_threshold.

I don't have a better mathmatical theory or derivation at this writing, but I 
do have an easy workaround for your consideration.  While phi_convict_threshold 
is adjustable, the period (or frequency) of Gossip messages is not.  Adjusting 
the gossip period to integrate over a longer time baseline reduced false 
positives from the Gossip failure detector.  The side effect increases the 
elapsed time to detect a legitimately-failed node.

Depending on user workload characteristics, and the related sources of latency 
(CPU, disk and network activity or transient delays) cited above, a System 
Architect could present a reasonable use case for controlling the Gossip 
message period.

The goal would be to set a detection window that accomodates common occurences 
for a given deployment scenario.  Not all data centers are created equal.

Patches and results from implementation will follow in subsequent posts.

*Potential Next Steps*
  Explore concern about sensitivity to gossip period.  Do the vnode gossip 
messages exceed capacity for peers to ingest?
  Explore concern about phi estimates from un-filled (new) deque.
  Explore concern about assuming Gaussian PDF.  Networks (not computers) 
generally characterize expected arrival time by Poisson distribution, not 
Gaussian.


 vnodes don't scale to hundreds of nodes
 ---

 Key: CASSANDRA-6127
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6127
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Any cluster that has vnodes and consists of hundreds of 
 physical nodes.
Reporter: Tupshin Harper
Assignee: Jonathan Ellis
 Attachments: 6000vnodes.patch, AdjustableGossipPeriod.patch, 
 delayEstimatorUntilStatisticallyValid.patch


 There are a lot of gossip-related issues related to very wide clusters that 
 also have vnodes enabled. Let's use this ticket as a master in case there are 
 sub-tickets.
 The most obvious symptom I've seen is with 1000 nodes in EC2 with m1.xlarge 
 instances. Each node configured with 32 vnodes.
 Without vnodes, cluster spins up fine and is ready to handle requests within 
 30 minutes or less. 
 With vnodes, nodes are reporting constant up/down flapping messages with no 
 external load on the cluster. After a couple of hours, they were still 
 flapping, had very high cpu load, and the cluster never looked like it was 
 going to stabilize or be useful for traffic.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6127) vnodes don't scale to hundreds of nodes

2013-10-24 Thread Brandon Williams (JIRA)

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

Brandon Williams commented on CASSANDRA-6127:
-

It would be helpful to dump the interval times for a node that is flapping 
(dumpInterArrivalTimes on the FD) so we can see how long the heartbeats are 
taking.  If some are excessively long, we need to get threads dumps/debugger 
timings from the gossiper to see if something is blocking it or taking a long 
time before changing any fundamentals (gossip interval, FD formula) that we 
already know work in principle without vnodes.  Increasing the payload size to 
32k shouldn't cause these problems, since that is only sent during initial 
state synchronization and isn't all that large to begin with.

 vnodes don't scale to hundreds of nodes
 ---

 Key: CASSANDRA-6127
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6127
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Any cluster that has vnodes and consists of hundreds of 
 physical nodes.
Reporter: Tupshin Harper
Assignee: Jonathan Ellis
 Attachments: 6000vnodes.patch, AdjustableGossipPeriod.patch, 
 delayEstimatorUntilStatisticallyValid.patch


 There are a lot of gossip-related issues related to very wide clusters that 
 also have vnodes enabled. Let's use this ticket as a master in case there are 
 sub-tickets.
 The most obvious symptom I've seen is with 1000 nodes in EC2 with m1.xlarge 
 instances. Each node configured with 32 vnodes.
 Without vnodes, cluster spins up fine and is ready to handle requests within 
 30 minutes or less. 
 With vnodes, nodes are reporting constant up/down flapping messages with no 
 external load on the cluster. After a couple of hours, they were still 
 flapping, had very high cpu load, and the cluster never looked like it was 
 going to stabilize or be useful for traffic.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


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

2013-10-24 Thread brandonwilliams
Merge branch 'cassandra-1.2' into cassandra-2.0


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

Branch: refs/heads/cassandra-2.0
Commit: 8bdd4733bf8412eca18e9b0b436e9def4c77a8d3
Parents: 21e6ec6 1f4070d
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 24 14:46:21 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 24 14:46:21 2013 -0500

--
 debian/cassandra.postinst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--




[1/6] git commit: Don't require the sysctl file to exist when deleting it

2013-10-24 Thread brandonwilliams
Updated Branches:
  refs/heads/cassandra-1.2 9eddaa8ff - 1f4070dbf
  refs/heads/cassandra-2.0 21e6ec6d8 - 8bdd4733b
  refs/heads/trunk fb7e0b1c2 - 723310252


Don't require the sysctl file to exist when deleting it


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

Branch: refs/heads/cassandra-1.2
Commit: 1f4070dbf29310962e3d632fe570ec3d8b61f887
Parents: 9eddaa8
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 24 14:46:00 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 24 14:46:00 2013 -0500

--
 debian/cassandra.postinst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f4070db/debian/cassandra.postinst
--
diff --git a/debian/cassandra.postinst b/debian/cassandra.postinst
index 9591459..752ff1f 100644
--- a/debian/cassandra.postinst
+++ b/debian/cassandra.postinst
@@ -45,7 +45,7 @@ case $1 in
 echo vm.max_map_count to 1048575 in the host. 2
 echo 2
 echo Deleting the local sysctl.d/cassandra.conf. 2
-rm -v /etc/sysctl.d/cassandra.conf
+rm -vf /etc/sysctl.d/cassandra.conf
 fi
 ;;
 



[2/6] git commit: Don't require the sysctl file to exist when deleting it

2013-10-24 Thread brandonwilliams
Don't require the sysctl file to exist when deleting it


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

Branch: refs/heads/cassandra-2.0
Commit: 1f4070dbf29310962e3d632fe570ec3d8b61f887
Parents: 9eddaa8
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 24 14:46:00 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 24 14:46:00 2013 -0500

--
 debian/cassandra.postinst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f4070db/debian/cassandra.postinst
--
diff --git a/debian/cassandra.postinst b/debian/cassandra.postinst
index 9591459..752ff1f 100644
--- a/debian/cassandra.postinst
+++ b/debian/cassandra.postinst
@@ -45,7 +45,7 @@ case $1 in
 echo vm.max_map_count to 1048575 in the host. 2
 echo 2
 echo Deleting the local sysctl.d/cassandra.conf. 2
-rm -v /etc/sysctl.d/cassandra.conf
+rm -vf /etc/sysctl.d/cassandra.conf
 fi
 ;;
 



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

2013-10-24 Thread brandonwilliams
Merge branch 'cassandra-1.2' into cassandra-2.0


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

Branch: refs/heads/trunk
Commit: 8bdd4733bf8412eca18e9b0b436e9def4c77a8d3
Parents: 21e6ec6 1f4070d
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 24 14:46:21 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 24 14:46:21 2013 -0500

--
 debian/cassandra.postinst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--




[jira] [Commented] (CASSANDRA-6233) Authentication is broken for the protocol v1 on C* 2.0

2013-10-24 Thread Vadim Chekan (JIRA)

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

Vadim Chekan commented on CASSANDRA-6233:
-

It seems authenticated login is not covered by any unit tests...

 Authentication is broken for the protocol v1 on C* 2.0
 --

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

 Attachments: 6233.txt


 CASSANDRA-5664 simplified the decoding method of CredentialsMessage by using 
 CBUtil.readStringMap (instead of duplicating the code). Unfortunately, that 
 latter method turns his keys to uppercase (to provide some form of case 
 insensitivity for keys), and in the case of CredentialsMessage this breaks 
 PasswordAuthenticator that expect lowercased keys (besides, it's a bad idea 
 to mess up with the case of the credentials map in general).
 Making CBUtil.readStringMap uppercase keys was probably a bad idea in the 
 first place (as nothing in the method name imply this), so attaching patch 
 that remove this (and uppercase keys specifically in StartupMessage where 
 that was done on purpose).



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CASSANDRA-6238) LOCAL_ONE doesn't work for SimpleStrategy

2013-10-24 Thread Alex Liu (JIRA)
Alex Liu created CASSANDRA-6238:
---

 Summary: LOCAL_ONE doesn't work for SimpleStrategy
 Key: CASSANDRA-6238
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6238
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Alex Liu
Assignee: Alex Liu


LOCAL_ONE only works for NetworkTopologyStrategy which has DC specification. 
Any other strategy fails.

If there is no  DC specified in the strategy, we should treat LOCAL_ONE as ONE



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Comment Edited] (CASSANDRA-6233) Authentication is broken for the protocol v1 on C* 2.0

2013-10-24 Thread Vadim Chekan (JIRA)

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

Vadim Chekan edited comment on CASSANDRA-6233 at 10/24/13 8:23 PM:
---

It seems authenticated login is not covered by any unit tests...
Would it be better to use apache's CaseInsensitiveMap?
http://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections4/map/CaseInsensitiveMap.html


was (Author: vchekan):
It seems authenticated login is not covered by any unit tests...

 Authentication is broken for the protocol v1 on C* 2.0
 --

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

 Attachments: 6233.txt


 CASSANDRA-5664 simplified the decoding method of CredentialsMessage by using 
 CBUtil.readStringMap (instead of duplicating the code). Unfortunately, that 
 latter method turns his keys to uppercase (to provide some form of case 
 insensitivity for keys), and in the case of CredentialsMessage this breaks 
 PasswordAuthenticator that expect lowercased keys (besides, it's a bad idea 
 to mess up with the case of the credentials map in general).
 Making CBUtil.readStringMap uppercase keys was probably a bad idea in the 
 first place (as nothing in the method name imply this), so attaching patch 
 that remove this (and uppercase keys specifically in StartupMessage where 
 that was done on purpose).



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6145) Include windows batch files for recently added shell commands (and some older ones)

2013-10-24 Thread Mikhail Stepura (JIRA)

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

Mikhail Stepura commented on CASSANDRA-6145:


Provided _cqlsh.bat_ just doesn't work
{code}
set DSDIR=%~dp0..

%DSDIR%\python\python.exe %DSDIR%\apache-cassandra\bin\cqlsh %*
{code}

_DSDIR_ there is a root folder for C* (i.e. folder in which _bin/_ subfolder 
resides)

 Include windows batch files for recently added shell commands (and some older 
 ones)
 ---

 Key: CASSANDRA-6145
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6145
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
 Environment: Windows
Reporter: Sven Delmas
Assignee: Sven Delmas
Priority: Trivial
 Fix For: 1.2.12

 Attachments: 6145-1.patch, 6145.patch


 - cassandra-shuffle.bat seems very different than the ones already there. As 
 far as I can tell the differences are cosmetic, so I consolidate that.
 - cassandra-stress.bat
 - cassandra-stressd.bat
 - cqlsh.bat
 - debug-cql.bat
 - sstableloader.bat
 - sstablemetadata.bat
 - sstablescrub.bat
 - sstablesplit.bat
 - sstableupgrade.bat
 Not all files apply to all branches, but I figure I better include all the 
 ones I have.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6232) Installation shouldn't fail if /etc/sysctl.d/cassandra is deleted

2013-10-24 Thread Faidon Liambotis (JIRA)

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

Faidon Liambotis commented on CASSANDRA-6232:
-

-f works and is a good idea nevertheless, but the warnings mentioning OpenVZ 
are still echo'ed if the file doesn't exist, which can be confusing.

I'd suggest also making the
{code:none}
if ! sysctl -p /etc/sysctl.d/cassandra.conf; then
{code}

line into
{code:none}
if [ -r /etc/sysctl.d/cassandra.conf ]  ! sysctl -p 
/etc/sysctl.d/cassandra.conf; then
{code}

 Installation shouldn't fail if /etc/sysctl.d/cassandra is deleted
 -

 Key: CASSANDRA-6232
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6232
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Reporter: Faidon Liambotis
Assignee: Brandon Williams
Priority: Minor
 Fix For: 1.2.12, 2.0.3


 The Debian package's postinst currently has this snippet code, under the 
 configure action (i.e. what runs when installing or upgrading):
 {code:none}
 if ! sysctl -p /etc/sysctl.d/cassandra.conf; then
 [...]
 rm -v /etc/sysctl.d/cassandra.conf
 fi
 {code}
 /etc/sysctl.d/cassandra.conf is a conffile and might be removed by the system 
 administrator. The sysadmin might not want this sysctl setting or have an 
 entirely different system of managing the /etc/sysctl.d hierarchy (in our 
 case that would be puppet).
 Since this piece of code doesn't check for the existence and doesn't use rm's 
 -f argument, if the file doesn't exist the rm call fails and the package 
 installation is aborted.
 I'd propose checking for the file's existence instead of just sysctl -p, so 
 that you can avoid the nasty warnings too, but adding -f to rm shouldn't hurt 
 either.
 Note that this would probably fail on package upgrades under OpenVZ too, 
 which according to the error message should be a supported configuration.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (CASSANDRA-6238) LOCAL_ONE doesn't work for SimpleStrategy

2013-10-24 Thread Alex Liu (JIRA)

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

Alex Liu updated CASSANDRA-6238:


Attachment: 6238.txt

 LOCAL_ONE doesn't work for SimpleStrategy
 -

 Key: CASSANDRA-6238
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6238
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Alex Liu
Assignee: Alex Liu
 Attachments: 6238.txt


 LOCAL_ONE only works for NetworkTopologyStrategy which has DC specification. 
 Any other strategy fails.
 If there is no  DC specified in the strategy, we should treat LOCAL_ONE as ONE



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CASSANDRA-6239) pidfile is never written, /etc/init.d/cassandra stop fails

2013-10-24 Thread Faidon Liambotis (JIRA)
Faidon Liambotis created CASSANDRA-6239:
---

 Summary: pidfile is never written, /etc/init.d/cassandra stop 
fails
 Key: CASSANDRA-6239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6239
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Reporter: Faidon Liambotis


The init script tries, via start-stop-daemon, to write a pidfile to 
/var/run/cassandra/cassandra.pid. /var/run/cassandra doesn't exist (righftully 
so, /var/run can be a tmpfs), so the init script has this stanza above the 
start-stop-daemon invocation:
{code:none}
[ -e `dirname PIDFILE` ] || \
install -d -ocassandra -gcassandra -m750 `dirname $PIDFILE`
{code}

The first line is missing the dollar sign before the PIDFILE variable (i.e. it 
should be 'dirname $PIDFILE'). This has the effect that dirname PIDFILE is 
called, with the PIDFILE as a literal, which always returns . as the output, 
which always exists, so the install call never gets executed, the directory 
never gets created and start-stop-daemon is unable to write the pidfile.

The pidfile is never written and /etc/init.d/cassandra stop never works.

Adding a $ before PIDFILE fixes the issue. This has been tested.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (CASSANDRA-6238) LOCAL_ONE doesn't work for SimpleStrategy

2013-10-24 Thread Brandon Williams (JIRA)

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

Brandon Williams updated CASSANDRA-6238:


 Reviewer: Jason Brown
Fix Version/s: 2.0.3
   1.2.12

 LOCAL_ONE doesn't work for SimpleStrategy
 -

 Key: CASSANDRA-6238
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6238
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Alex Liu
Assignee: Alex Liu
 Fix For: 1.2.12, 2.0.3

 Attachments: 6238.txt


 LOCAL_ONE only works for NetworkTopologyStrategy which has DC specification. 
 Any other strategy fails.
 If there is no  DC specified in the strategy, we should treat LOCAL_ONE as ONE



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CASSANDRA-6240) CLASSPATH logic from init script is unused, JNA isn't loaded

2013-10-24 Thread Faidon Liambotis (JIRA)
Faidon Liambotis created CASSANDRA-6240:
---

 Summary: CLASSPATH logic from init script is unused, JNA isn't 
loaded
 Key: CASSANDRA-6240
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6240
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Reporter: Faidon Liambotis


The init script has a classpath() function that collects all the jars and even 
includes this piece of code to work with the standard Debian/Ubuntu libjna-jar:
{code:none}
# use JNA if installed in standard location
[ -r /usr/share/java/jna.jar ]  cp=$cp:/usr/share/java/jna.jar
{code}

This seems very nice and correct, however the classpath() function is never 
called and is entirely unused :) Instead, /usr/bin/cassandra is called, which 
in turn includes /usr/share/cassandra/cassandra.in.sh, which has basically 
similar code to collect the jars for CLASSPATH but a) without the JNA standard 
path trick b) without using EXTRA_CLASSPATH (from /etc/default/cassandra) at 
all, so Cassandra boots without either JNA nor EXTRA_CLASSPATH, contrary to 
expectations.

There are various suggestions on the web to do ln -s /usr/share/java/jna.jar 
/usr/share/cassandra/lib/; I suspect this bug to be the reason for that.

 /usr/share/cassandra/cassandra.in.sh seems smart enough to append but not 
overwrite CLASSPATH, so fixing the init script's classpath() to only include 
JNA + EXTRA_CLASSPATH (and making sure it's actually getting called :)) should 
be enough for a fix.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (CASSANDRA-6145) Include windows batch files for recently added shell commands (and some older ones)

2013-10-24 Thread Mikhail Stepura (JIRA)

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

Mikhail Stepura updated CASSANDRA-6145:
---

Attachment: cassandra-2.0-6145-cqlsh.bat.patch

Here is the patch, assuming that Python installer always put the python in the 
PATH

 Include windows batch files for recently added shell commands (and some older 
 ones)
 ---

 Key: CASSANDRA-6145
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6145
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
 Environment: Windows
Reporter: Sven Delmas
Assignee: Sven Delmas
Priority: Trivial
 Fix For: 1.2.12

 Attachments: 6145-1.patch, 6145.patch, 
 cassandra-2.0-6145-cqlsh.bat.patch


 - cassandra-shuffle.bat seems very different than the ones already there. As 
 far as I can tell the differences are cosmetic, so I consolidate that.
 - cassandra-stress.bat
 - cassandra-stressd.bat
 - cqlsh.bat
 - debug-cql.bat
 - sstableloader.bat
 - sstablemetadata.bat
 - sstablescrub.bat
 - sstablesplit.bat
 - sstableupgrade.bat
 Not all files apply to all branches, but I figure I better include all the 
 ones I have.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6083) Pig requires explicit cast from int to long to save to Cassandra

2013-10-24 Thread Alex Liu (JIRA)

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

Alex Liu commented on CASSANDRA-6083:
-

It works for cassandra-1.2 as the following testing

{code}
 CREATE TABLE test1 (a int PRIMARY KEY, b bigint);
 CREATE TABLE moredata1 (x int PRIMARY KEY, y int);
 INSERT INTO test1 (a,b) VALUES (1,1);
 INSERT INTO test1 (a,b) VALUES (2,2);
 INSERT INTO test1 (a,b) VALUES (3,3);
 INSERT INTO moredata1 (x, y) VALUES (4,4);
 INSERT INTO moredata1 (x, y) VALUES (5,5);
 INSERT INTO moredata1 (x, y) VALUES (6,6);


moretestvalues= LOAD 'cql://cql3ks/moredata1' USING CqlStorage(););
insertformat= FOREACH moretestvalues GENERATE 
TOTUPLE(TOTUPLE('a',x)),TOTUPLE(y);
STORE insertformat INTO 
'cql://cql3ks/test1?output_query=UPDATE+cql3ks.test1+set+b+%3D+%3F' USING 
CqlStorage();
result= LOAD 'cql://cql3ks/test1' USING CqlStorage(););
dump result;

{code}

 Pig requires explicit cast from int to long to save to Cassandra
 

 Key: CASSANDRA-6083
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6083
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Chad Johnston
Assignee: Alex Liu
Priority: Minor

 Since version 1.2.10, I have to manually cast any int values in Pig to long 
 in order to store them into bigint Cassandra columns. I did not have to 
 perform this cast in previous versions of Cassandra.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-5936) Improve the way we pick L0 compaction candidates

2013-10-24 Thread T Jake Luciani (JIRA)

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

T Jake Luciani commented on CASSANDRA-5936:
---

https://code.google.com/p/leveldb/source/browse/db/version_set.cc#507

 Improve the way we pick L0 compaction candidates
 

 Key: CASSANDRA-5936
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5936
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
 Fix For: 2.1


 We could improve the way we pick compaction candidates in level 0 in LCS.
 The most common way for us to get behind on compaction is after repairs, we 
 should exploit the fact that the streamed sstables are most often very narrow 
 in range since the other nodes in the ring will have a similar 
 sstable-range-distribution. We should in theory be able to do 10 concurrent 
 compactions involving L1 - ie, partition L0 in buckets defined by the 
 sstables in L1 to only keep one L1 SSTable busy for every compaction (be it 
 L1 to L2 or L0 to L1).
 we will need some heuristics on when to select candidates from the buckets 
 and when to do it the old way (since L0 sstables can span several L1 sstables)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 1_Import Casandra.png
Attachment size: 121487
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=1_Import+Casandra.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[jira] [Assigned] (CASSANDRA-6240) CLASSPATH logic from init script is unused, JNA isn't loaded

2013-10-24 Thread Brandon Williams (JIRA)

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

Brandon Williams reassigned CASSANDRA-6240:
---

Assignee: Eric Evans

 CLASSPATH logic from init script is unused, JNA isn't loaded
 

 Key: CASSANDRA-6240
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6240
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Reporter: Faidon Liambotis
Assignee: Eric Evans

 The init script has a classpath() function that collects all the jars and 
 even includes this piece of code to work with the standard Debian/Ubuntu 
 libjna-jar:
 {code:none}
 # use JNA if installed in standard location
 [ -r /usr/share/java/jna.jar ]  cp=$cp:/usr/share/java/jna.jar
 {code}
 This seems very nice and correct, however the classpath() function is never 
 called and is entirely unused :) Instead, /usr/bin/cassandra is called, which 
 in turn includes /usr/share/cassandra/cassandra.in.sh, which has basically 
 similar code to collect the jars for CLASSPATH but a) without the JNA 
 standard path trick b) without using EXTRA_CLASSPATH (from 
 /etc/default/cassandra) at all, so Cassandra boots without either JNA nor 
 EXTRA_CLASSPATH, contrary to expectations.
 There are various suggestions on the web to do ln -s /usr/share/java/jna.jar 
 /usr/share/cassandra/lib/; I suspect this bug to be the reason for that.
  /usr/share/cassandra/cassandra.in.sh seems smart enough to append but not 
 overwrite CLASSPATH, so fixing the init script's classpath() to only include 
 JNA + EXTRA_CLASSPATH (and making sure it's actually getting called :)) 
 should be enough for a fix.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 2_Import as Eclipse project.png
Attachment size: 31048
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=2_Import+as+Eclipse+project.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 3_Select Project Directory.png
Attachment size: 46549
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=3_Select+Project+Directory.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 7_JDK and Language Level Change.png
Attachment size: 101385
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=7_JDK+and+Language+Level+Change.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 6_Select Project Structure.png
Attachment size: 65676
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=6_Select+Project+Structure.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 4_Finalize Import.png
Attachment size: 26854
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=4_Finalize+Import.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 8_Language Level Change - Restart IDEA.png
Attachment size: 29649
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=8_Language+Level+Change+-+Restart+IDEA.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 9_Adding Ant Config.png
Attachment size: 128799
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=9_Adding+Ant+Config.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 3_Select Project Directory.png
Attachment size: 44720
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=3_Select+Project+Directory.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 1_Import Casandra.png
Attachment size: 97654
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=1_Import+Casandra.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 2_Import as Eclipse project.png
Attachment size: 29054
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=2_Import+as+Eclipse+project.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 6_Select Project Structure.png
Attachment size: 50762
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=6_Select+Project+Structure.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 7_JDK and Language Level Change.png
Attachment size: 82713
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=7_JDK+and+Language+Level+Change.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 4_Finalize Import.png
Attachment size: 25360
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=4_Finalize+Import.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 5_Import Completed.png
Attachment size: 122864
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=5_Import+Completed.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 8_Language Level Change - Restart IDEA.png
Attachment size: 24260
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=8_Language+Level+Change+-+Restart+IDEA.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 10_Successful Build.png
Attachment size: 135939
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=10_Successful+Build.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 11_IDEA C_ Logs.png
Attachment size: 209062
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=11_IDEA+C_+Logs.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: 9_Adding Ant Config.png
Attachment size: 104114
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=9_Adding+Ant+Config.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[jira] [Updated] (CASSANDRA-6238) LOCAL_ONE doesn't work for SimpleStrategy

2013-10-24 Thread Alex Liu (JIRA)

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

Alex Liu updated CASSANDRA-6238:


Attachment: 6238-v2.txt

 LOCAL_ONE doesn't work for SimpleStrategy
 -

 Key: CASSANDRA-6238
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6238
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Alex Liu
Assignee: Alex Liu
 Fix For: 1.2.12, 2.0.3

 Attachments: 6238.txt, 6238-v2.txt


 LOCAL_ONE only works for NetworkTopologyStrategy which has DC specification. 
 Any other strategy fails.
 If there is no  DC specified in the strategy, we should treat LOCAL_ONE as ONE



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6238) LOCAL_ONE doesn't work for SimpleStrategy

2013-10-24 Thread Alex Liu (JIRA)

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

Alex Liu commented on CASSANDRA-6238:
-

6238.txt change only for LOCAL_ONE.
6238-v2.txt change is for both LOCAL_ONE and LOCAL_QUORUM

I am not sure that we want LOCAL_QUORUM to support SimpleStrategy as well, so I 
attach v2 for reference.

 LOCAL_ONE doesn't work for SimpleStrategy
 -

 Key: CASSANDRA-6238
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6238
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Alex Liu
Assignee: Alex Liu
 Fix For: 1.2.12, 2.0.3

 Attachments: 6238.txt, 6238-v2.txt


 LOCAL_ONE only works for NetworkTopologyStrategy which has DC specification. 
 Any other strategy fails.
 If there is no  DC specified in the strategy, we should treat LOCAL_ONE as ONE



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (CASSANDRA-6101) Debian init script broken

2013-10-24 Thread Brandon Williams (JIRA)

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

Brandon Williams updated CASSANDRA-6101:


Fix Version/s: 2.0.2

 Debian init script broken
 -

 Key: CASSANDRA-6101
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6101
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Anton Winter
Assignee: Eric Evans
Priority: Minor
 Fix For: 2.0.2

 Attachments: 6101-classpath.patch, 6101.txt


 The debian init script released in 2.0.1 contains 2 issues:
 # The pidfile directory is not created if it doesn't already exist.
 # Classpath not exported to the start-stop-daemon.
 These lead to the init script not picking up jna.jar, or anything from the 
 debian EXTRA_CLASSPATH environment variable, and the init script not being 
 able to stop/restart Cassandra.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Resolved] (CASSANDRA-6239) pidfile is never written, /etc/init.d/cassandra stop fails

2013-10-24 Thread Brandon Williams (JIRA)

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

Brandon Williams resolved CASSANDRA-6239.
-

Resolution: Duplicate

 pidfile is never written, /etc/init.d/cassandra stop fails
 

 Key: CASSANDRA-6239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6239
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Reporter: Faidon Liambotis

 The init script tries, via start-stop-daemon, to write a pidfile to 
 /var/run/cassandra/cassandra.pid. /var/run/cassandra doesn't exist 
 (righftully so, /var/run can be a tmpfs), so the init script has this stanza 
 above the start-stop-daemon invocation:
 {code:none}
 [ -e `dirname PIDFILE` ] || \
 install -d -ocassandra -gcassandra -m750 `dirname $PIDFILE`
 {code}
 The first line is missing the dollar sign before the PIDFILE variable (i.e. 
 it should be 'dirname $PIDFILE'). This has the effect that dirname 
 PIDFILE is called, with the PIDFILE as a literal, which always returns . 
 as the output, which always exists, so the install call never gets 
 executed, the directory never gets created and start-stop-daemon is unable to 
 write the pidfile.
 The pidfile is never written and /etc/init.d/cassandra stop never works.
 Adding a $ before PIDFILE fixes the issue. This has been tested.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: idea_run.png
Attachment size: 
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=idea_run.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[jira] [Commented] (CASSANDRA-6083) Pig requires explicit cast from int to long to save to Cassandra

2013-10-24 Thread Chad Johnston (JIRA)

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

Chad Johnston commented on CASSANDRA-6083:
--

I ran into the issue when loading a file from disk and saving it into 
Cassandra. I'll put together a reproducible case.

There's a small chance that this was fixed with the changes for 
https://issues.apache.org/jira/browse/CASSANDRA-6102.

I'll generate my test case against 1.2.10 and see if it's still an issue in 
1.2.11.

 Pig requires explicit cast from int to long to save to Cassandra
 

 Key: CASSANDRA-6083
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6083
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Chad Johnston
Assignee: Alex Liu
Priority: Minor

 Since version 1.2.10, I have to manually cast any int values in Pig to long 
 in order to store them into bigint Cassandra columns. I did not have to 
 perform this cast in previous versions of Cassandra.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6127) vnodes don't scale to hundreds of nodes

2013-10-24 Thread Brandon Williams (JIRA)

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

Brandon Williams commented on CASSANDRA-6127:
-

Can you see if adding -Dcassandra.unsafesystem=true allows the cluster to 
stabilize at some point?

 vnodes don't scale to hundreds of nodes
 ---

 Key: CASSANDRA-6127
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6127
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Any cluster that has vnodes and consists of hundreds of 
 physical nodes.
Reporter: Tupshin Harper
Assignee: Jonathan Ellis
 Attachments: 6000vnodes.patch, AdjustableGossipPeriod.patch, 
 delayEstimatorUntilStatisticallyValid.patch


 There are a lot of gossip-related issues related to very wide clusters that 
 also have vnodes enabled. Let's use this ticket as a master in case there are 
 sub-tickets.
 The most obvious symptom I've seen is with 1000 nodes in EC2 with m1.xlarge 
 instances. Each node configured with 32 vnodes.
 Without vnodes, cluster spins up fine and is ready to handle requests within 
 30 minutes or less. 
 With vnodes, nodes are reporting constant up/down flapping messages with no 
 external load on the cluster. After a couple of hours, they were still 
 flapping, had very high cpu load, and the cluster never looked like it was 
 going to stabilize or be useful for traffic.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: Cassandra Logs via IDEA.png
Attachment size: 252562
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=Cassandra+Logs+via+IDEA.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: Run Configuration.png
Attachment size: 76522
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=Run+Configuration.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[Cassandra Wiki] New attachment added to page RunningCassandraInIDEA

2013-10-24 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page RunningCassandraInIDEA for change 
notification. An attachment has been added to that page by LyubenTodorov. 
Following detailed information is available:

Attachment name: Adding Ant Config.png
Attachment size: 168472
Attachment link: 
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=AttachFiledo=gettarget=Adding+Ant+Config.png
Page link: https://wiki.apache.org/cassandra/RunningCassandraInIDEA


[jira] [Commented] (CASSANDRA-6142) Remove multithreaded compaction

2013-10-24 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-6142:
---

Posted 2.0 fixes to https://github.com/jbellis/cassandra/commits/6142-2.0.  
Note that b959e8ff3bccd3437de70d33da91307ab9c12a19 is a different, 
less-invasive approach than the one taken for trunk.

 Remove multithreaded compaction
 ---

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


 There is at best a very small sweet spot for multithreaded compaction 
 (ParallelCompactionIterable).  For large rows, we stall the pipeline and fall 
 back to a single LCR pass.  For small rows, the overhead of the coordination 
 outweighs the benefits of parallelization (45s to compact 2x1M stress rows 
 with multithreading enabled, vs 35 with it disabled).



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[Cassandra Wiki] Update of RunningCassandraInIDEA by LyubenTodorov

2013-10-24 Thread Apache Wiki
Dear Wiki user,

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

The RunningCassandraInIDEA page has been changed by LyubenTodorov:
https://wiki.apache.org/cassandra/RunningCassandraInIDEA?action=diffrev1=23rev2=24

  IDEA is now open source!  The free community edition at 
http://www.jetbrains.org is all you need for Cassandra development.  (You don't 
need J2EE or Web tools.)
  
- You can create an IntelliJ project in just two steps:
+ To quickly import Cassandra into IntelliJ and start coding simply:
  
   1. Run ant generate-eclipse-files
-  1. File - Import Project
+  2. File - Import Project
  
- If you want to get up close and personal with setting it up manually instead 
of cheating like that, read on...
+ If you want IDEA to handle more of the environment for you, keep reading.
  
  TableOfContents
  
- = Setup Cassandra as a project =
+ = Setup Cassandra as a Project =
- Preconditions: JDK6 and Ant (http://ant.apache.org/)
  
- IDEA will generally set the project up properly for you (you'll need to run 
some ant targets and add a couple of folders as content roots).
+ ''' Prerequisites: ''' JDK6 (Cassandra 1.2) or JDK7 (Cassandra 2.0+), Apache 
Ant (http://ant.apache.org/) and Git (http://git-scm.com/)  are required to get 
Cassandra running in IDEA. 
  
- Open IDEA and Select Check out from Version Control under Quick Start and 
select 'Git' or 'Subversion' (this tutorial will use Git). (The URL to the 
Apache Cassandra svn is https://svn.apache.org/repos/asf/cassandra/trunk, the 
'Git Repository URL' is git://git.apache.org/cassandra.git)
+  1. Clone Cassandra from apache's Git repository. BRBR
+  for trunk branch (JDK7 required)
+  {{{ 
+  git clone git://git.apache.org/cassandra.git
+  }}}
+  for cassandra-1.2 branch
+  {{{
+  git clone –b cassandra-1.2 git://git.apache.org/cassandra.git 
+  }}}
+  2. Once git has finished cloning the repository, generate the eclipse files 
using ant.
+  {{{
+  ant generate-eclipse-files
+  }}} 
+  3. Start IDEA
+  4. Click '''Import Project'''.
+  5. Navigate to the newly cloned cassandra directory and click '''OK'''.
  
- {{attachment:CheckOutFromVersionControl-1.png}}
+  {{attachment:1_Import Casandra.png}}
+  BRBR
+  6. Select '''Import project from external model''', pick '''Eclipse''' then 
click '''OK'''.
  
- Parent directory is where IDEA will place the Cassandra checkout/clone. Press 
Clone to engage the checkout/clone (be patient, will take some time).  Answer 
'Yes' to Would you like to create an IntelliJ IDEA project for the sources you 
have checked out to /Users/schildmeijer/workspace/cassandra?
+  {{attachment:2_Import as Eclipse project.png}}
+  BRBR
+  7. Select '''Next'''
  
- {{attachment:CloneRepository-2.png}}
+  {{attachment:3_Select Project Directory.png}}
+  BRBR
+  8. Select '''cassandra''' and click '''Finish'''. You now have a 
successfully imported Cassandra project.
  
- Choose Create Java project from existing sources.
+  {{attachment:5_Import Completed.png}}
+  BRBR
  
- {{attachment:CreateProjectFromExistingSources-3.png}}
+ = Building  Testing Cassandra via Ant =
  
- Pick an appropriate name for the new project (e.g cassandra) 'Project files 
location' is where on the file system IDEA will create your Java project.
+ To build Cassandra we need to import ant's build file, aka '''build.xml'''. 
  
- {{attachment:NewProject-4.png}}
  
- Add the following Java source files to your module.
+  1. Select the '''Ant Build''' tab from IDEA (right hand side in the screen 
shot below).
+  2. Select the '''+''' (Add).
+  3. Navigate to Cassandra's root directory (based on the tutorial this would 
be ~/workspace/cassandra/) and select '''build.xml'''.
+  4. Click '''OK'''.
  
-  * interface/thrift/gen-java
-  * src/java
-  * test/unit
+  The different ant targets will now be available for execution. 
+  {{attachment:Adding Ant Config.png}}
+  BRBR
  
- {{attachment:NewProjectChooseModules-5.png}}
+  '''Building / Testing Cassandra via Ant''' BR
+  Once the ant build file is added to IDEA you can compile cassandra via the 
'''build''' target. The unit tests are located under the '''test''' 
target.BR
+  To run a target '''select''' it and then click {{attachment:idea_run.png}}.
  
- Press 'Next' followed by 'Finish' after you have reviewed the suggested 
module structure. I recommend to only have one module (Cassandra).
+  {{attachment:10_Successful Build.png}}
  
- {{attachment:NewProjectReviewLibrariesFound-6.png}} 
{{attachment:NewProjectReviewModuleStructure-7.png}}
+ = Create a RUN configuration =
  
- Your project will be now imported into the IDEA project workspace. Wait until 
the project indexing is done. (This might take some time depending on your 
computer)
+  1. Select '''Run'''  '''Edit Configurations...''' and click the '''+''' 
(Add New Configuration).BR
+  2. Populate the config with the following:BR
  
- Your IDEA project workspace should now look something like this:
+  

[jira] [Commented] (CASSANDRA-6135) Add beforeChange Notification to Gossiper State.

2013-10-24 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-6135:
---

I'd vote for committing v2 (the simpler version) to 2.0 only, and adding a NEWS 
entry.

 Add beforeChange Notification to Gossiper State.
 

 Key: CASSANDRA-6135
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6135
 Project: Cassandra
  Issue Type: New Feature
Reporter: Benjamin Coverston
Assignee: Sergio Bossa
 Attachments: 
 0001-New-Gossiper-notification-to-IEndpointStateChangeSub.patch, 
 0002-CASSANDRA-6135.diff, CASSANDRA-6135-V3.patch


 We would like an internal notification to be fired before state changes 
 happen so we can intercept them, and in some cases defer them.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6234) Add metrics for native protocols

2013-10-24 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-6234:
---

Isn't this the same as CASSANDRA-5084?

 Add metrics for native protocols
 

 Key: CASSANDRA-6234
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6234
 Project: Cassandra
  Issue Type: New Feature
Reporter: Adam Hattrell
Assignee: Sylvain Lebresne

 It would be very useful to expose metrics related to the native protocol.
 Initially I have a user that would like to be able to monitor the usage of 
 native transport threads.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6216) Level Compaction should persist last compacted key per level

2013-10-24 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-6216:
---

bq. should we not pick those sstables which have the largest overlapping with 
sstables in the higer level. 

+1.  IIRC HyperDex does this in their leveldb fork.

bq. this might cause starvation to some sstables as they wont get a chance to 
compact.

Well, if they're worse candidates, I'm okay with starving them. :)

(We will force compaction of an sstable that has too many expired tombstones 
already, so tombstones living forever shouldn't be a problem.)

 Level Compaction should persist last compacted key per level
 

 Key: CASSANDRA-6216
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6216
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: sankalp kohli
Assignee: sankalp kohli
Priority: Minor

 Level compaction does not persist the last compacted key per level. This is 
 important for higher levels. 
 The sstables with higher token and in higher levels wont get a chance to 
 compact as the last compacted key will get reset after a restart.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6109) Consider coldness in STCS compaction

2013-10-24 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-6109:
---

That sounds pretty straightforward.

When they make up more than X% do we stop discriminating or merge them only 
with other cold sstables?

 Consider coldness in STCS compaction
 

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

 Attachments: 6109-v1.patch, 6109-v2.patch


 I see two options:
 # Don't compact cold sstables at all
 # Compact cold sstables only if there is nothing more important to compact
 The latter is better if you have cold data that may become hot again...  but 
 it's confusing if you have a workload such that you can't keep up with *all* 
 compaction, but you can keep up with hot sstable.  (Compaction backlog stat 
 becomes useless since we fall increasingly behind.)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-6182) Unable to modify column_metadata via thrift

2013-10-24 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-6182:
---

+1

 Unable to modify column_metadata via thrift
 ---

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

 Attachments: 6182.txt


 Reproduced on 2.0 HEAD
 {noformat}
 [default@unknown] use opscenter;
 Authenticated to keyspace: OpsCenter
 [default@OpsCenter] create column family test with column_metadata = 
 [{column_name: '', validation_class: LongType}];
 637fffa1-a10f-3d89-8be6-8a316af05dd2
 [default@OpsCenter] update column family test with column_metadata=[];
 e49e435b-ba2a-3a08-8af0-32b897b872b8
 [default@OpsCenter] show schema;
 other entries removed
 create column family test
   with column_type = 'Standard'
   and comparator = 'BytesType'
   and default_validation_class = 'BytesType'
   and key_validation_class = 'BytesType'
   and read_repair_chance = 0.1
   and dclocal_read_repair_chance = 0.0
   and populate_io_cache_on_flush = false
   and gc_grace = 864000
   and min_compaction_threshold = 4
   and max_compaction_threshold = 32
   and replicate_on_write = true
   and compaction_strategy = 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
   and caching = 'KEYS_ONLY'
   and default_time_to_live = 0
   and speculative_retry = 'NONE'
   and column_metadata = [
 {column_name : '',
 validation_class : LongType}]
   and compression_options = {'sstable_compression' : 
 'org.apache.cassandra.io.compress.LZ4Compressor'}
   and index_interval = 128;
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CASSANDRA-5201) Cassandra/Hadoop does not support current Hadoop releases

2013-10-24 Thread Ken Krugler (JIRA)

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

Ken Krugler commented on CASSANDRA-5201:


Re Hadoop 1.x vs. Hadoop 2.x - most companies I see are using a 1.x version of 
Hadoop. Usage of Hadoop 2.x is ramping up fast, but I'm guessing it will be at 
least another year (probably more) before you'd want to start thinking about 
phasing out support for Hadoop 1.x

 Cassandra/Hadoop does not support current Hadoop releases
 -

 Key: CASSANDRA-5201
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5201
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Affects Versions: 1.2.0
Reporter: Brian Jeltema
Assignee: Dave Brosius
 Attachments: 5201_a.txt


 Using Hadoop 0.22.0 with Cassandra results in the stack trace below.
 It appears that version 0.21+ changed org.apache.hadoop.mapreduce.JobContext
 from a class to an interface.
 Exception in thread main java.lang.IncompatibleClassChangeError: Found 
 interface org.apache.hadoop.mapreduce.JobContext, but class was expected
   at 
 org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSplits(ColumnFamilyInputFormat.java:103)
   at 
 org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:445)
   at 
 org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:462)
   at 
 org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:357)
   at org.apache.hadoop.mapreduce.Job$2.run(Job.java:1045)
   at org.apache.hadoop.mapreduce.Job$2.run(Job.java:1042)
   at java.security.AccessController.doPrivileged(Native Method)
   at javax.security.auth.Subject.doAs(Subject.java:415)
   at 
 org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1153)
   at org.apache.hadoop.mapreduce.Job.submit(Job.java:1042)
   at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1062)
   at MyHadoopApp.run(MyHadoopApp.java:163)
   at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:69)
   at MyHadoopApp.main(MyHadoopApp.java:82)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:601)
   at org.apache.hadoop.util.RunJar.main(RunJar.java:192)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


git commit: assume python is on path for windows for cqlsh.bat patch by mstepura reviewed by dbrosius for cassandra-6145

2013-10-24 Thread dbrosius
Updated Branches:
  refs/heads/cassandra-1.2 1f4070dbf - 08a22729a


assume python is on path for windows for cqlsh.bat
patch by mstepura reviewed by dbrosius for cassandra-6145


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

Branch: refs/heads/cassandra-1.2
Commit: 08a22729afedb53dfa988b3e2db34b7a743977de
Parents: 1f4070d
Author: Dave Brosius dbros...@mebigfatguy.com
Authored: Fri Oct 25 00:14:30 2013 -0400
Committer: Dave Brosius dbros...@mebigfatguy.com
Committed: Fri Oct 25 00:14:30 2013 -0400

--
 bin/cqlsh.bat | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/08a22729/bin/cqlsh.bat
--
diff --git a/bin/cqlsh.bat b/bin/cqlsh.bat
index e54aebf..a61df21 100644
--- a/bin/cqlsh.bat
+++ b/bin/cqlsh.bat
@@ -1,5 +1,30 @@
-@echo off
+@REM
+@REM  Licensed to the Apache Software Foundation (ASF) under one or more
+@REM  contributor license agreements.  See the NOTICE file distributed with
+@REM  this work for additional information regarding copyright ownership.
+@REM  The ASF licenses this file to You under the Apache License, Version 2.0
+@REM  (the License); you may not use this file except in compliance with
+@REM  the License.  You may obtain a copy of the License at
+@REM
+@REM  http://www.apache.org/licenses/LICENSE-2.0
+@REM
+@REM  Unless required by applicable law or agreed to in writing, software
+@REM  distributed under the License is distributed on an AS IS BASIS,
+@REM  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+@REM  See the License for the specific language governing permissions and
+@REM  limitations under the License.
 
-set DSDIR=%~dp0..
+if %OS% == Windows_NT setlocal
 
-%DSDIR%\python\python.exe %DSDIR%\apache-cassandra\bin\cqlsh %*
\ No newline at end of file
+python -V nul 21
+if ERRORLEVEL 1 goto err
+
+python %~dp0\cqlsh %*
+goto finally
+
+:err
+echo Can't detect Python version!
+
+:finally
+
+ENDLOCAL



[1/2] git commit: assume python is on path for windows for cqlsh.bat patch by mstepura reviewed by dbrosius for cassandra-6145

2013-10-24 Thread dbrosius
Updated Branches:
  refs/heads/cassandra-2.0 8bdd4733b - 3dc4e6563


assume python is on path for windows for cqlsh.bat
patch by mstepura reviewed by dbrosius for cassandra-6145


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

Branch: refs/heads/cassandra-2.0
Commit: 08a22729afedb53dfa988b3e2db34b7a743977de
Parents: 1f4070d
Author: Dave Brosius dbros...@mebigfatguy.com
Authored: Fri Oct 25 00:14:30 2013 -0400
Committer: Dave Brosius dbros...@mebigfatguy.com
Committed: Fri Oct 25 00:14:30 2013 -0400

--
 bin/cqlsh.bat | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/08a22729/bin/cqlsh.bat
--
diff --git a/bin/cqlsh.bat b/bin/cqlsh.bat
index e54aebf..a61df21 100644
--- a/bin/cqlsh.bat
+++ b/bin/cqlsh.bat
@@ -1,5 +1,30 @@
-@echo off
+@REM
+@REM  Licensed to the Apache Software Foundation (ASF) under one or more
+@REM  contributor license agreements.  See the NOTICE file distributed with
+@REM  this work for additional information regarding copyright ownership.
+@REM  The ASF licenses this file to You under the Apache License, Version 2.0
+@REM  (the License); you may not use this file except in compliance with
+@REM  the License.  You may obtain a copy of the License at
+@REM
+@REM  http://www.apache.org/licenses/LICENSE-2.0
+@REM
+@REM  Unless required by applicable law or agreed to in writing, software
+@REM  distributed under the License is distributed on an AS IS BASIS,
+@REM  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+@REM  See the License for the specific language governing permissions and
+@REM  limitations under the License.
 
-set DSDIR=%~dp0..
+if %OS% == Windows_NT setlocal
 
-%DSDIR%\python\python.exe %DSDIR%\apache-cassandra\bin\cqlsh %*
\ No newline at end of file
+python -V nul 21
+if ERRORLEVEL 1 goto err
+
+python %~dp0\cqlsh %*
+goto finally
+
+:err
+echo Can't detect Python version!
+
+:finally
+
+ENDLOCAL



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

2013-10-24 Thread dbrosius
Merge branch 'cassandra-1.2' into cassandra-2.0


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

Branch: refs/heads/cassandra-2.0
Commit: 3dc4e656370103ee616288a536f7758712b1ef91
Parents: 8bdd473 08a2272
Author: Dave Brosius dbros...@mebigfatguy.com
Authored: Fri Oct 25 00:19:11 2013 -0400
Committer: Dave Brosius dbros...@mebigfatguy.com
Committed: Fri Oct 25 00:19:11 2013 -0400

--
 bin/cqlsh.bat | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3dc4e656/bin/cqlsh.bat
--
diff --cc bin/cqlsh.bat
index 36023ea,a61df21..79adcff
--- a/bin/cqlsh.bat
+++ b/bin/cqlsh.bat
@@@ -1,21 -1,30 +1,33 @@@
  @REM
 -@REM  Licensed to the Apache Software Foundation (ASF) under one or more
 -@REM  contributor license agreements.  See the NOTICE file distributed with
 -@REM  this work for additional information regarding copyright ownership.
 -@REM  The ASF licenses this file to You under the Apache License, Version 2.0
 -@REM  (the License); you may not use this file except in compliance with
 -@REM  the License.  You may obtain a copy of the License at
 +@REM Licensed to the Apache Software Foundation (ASF) under one or more
 +@REM contributor license agreements. See the NOTICE file distributed with
 +@REM this work for additional information regarding copyright ownership.
 +@REM The ASF licenses this file to You under the Apache License, Version 2.0
 +@REM (the License); you may not use this file except in compliance with
 +@REM the License. You may obtain a copy of the License at
  @REM
 -@REM  http://www.apache.org/licenses/LICENSE-2.0
 +@REM http://www.apache.org/licenses/LICENSE-2.0
  @REM
 -@REM  Unless required by applicable law or agreed to in writing, software
 -@REM  distributed under the License is distributed on an AS IS BASIS,
 -@REM  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 -@REM  See the License for the specific language governing permissions and
 -@REM  limitations under the License.
 +@REM Unless required by applicable law or agreed to in writing, software
 +@REM distributed under the License is distributed on an AS IS BASIS,
 +@REM WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 +@REM See the License for the specific language governing permissions and
 +@REM limitations under the License.
 +
 +@echo off
  
- set DSDIR=%~dp0..
+ if %OS% == Windows_NT setlocal
+ 
+ python -V nul 21
+ if ERRORLEVEL 1 goto err
+ 
+ python %~dp0\cqlsh %*
+ goto finally
+ 
+ :err
+ echo Can't detect Python version!
+ 
+ :finally
+ 
+ ENDLOCAL
 +
- %DSDIR%\python\python.exe %DSDIR%\apache-cassandra\bin\cqlsh %*



[1/3] git commit: assume python is on path for windows for cqlsh.bat patch by mstepura reviewed by dbrosius for cassandra-6145

2013-10-24 Thread dbrosius
Updated Branches:
  refs/heads/trunk 723310252 - 8fbdc9f82


assume python is on path for windows for cqlsh.bat
patch by mstepura reviewed by dbrosius for cassandra-6145


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

Branch: refs/heads/trunk
Commit: 08a22729afedb53dfa988b3e2db34b7a743977de
Parents: 1f4070d
Author: Dave Brosius dbros...@mebigfatguy.com
Authored: Fri Oct 25 00:14:30 2013 -0400
Committer: Dave Brosius dbros...@mebigfatguy.com
Committed: Fri Oct 25 00:14:30 2013 -0400

--
 bin/cqlsh.bat | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/08a22729/bin/cqlsh.bat
--
diff --git a/bin/cqlsh.bat b/bin/cqlsh.bat
index e54aebf..a61df21 100644
--- a/bin/cqlsh.bat
+++ b/bin/cqlsh.bat
@@ -1,5 +1,30 @@
-@echo off
+@REM
+@REM  Licensed to the Apache Software Foundation (ASF) under one or more
+@REM  contributor license agreements.  See the NOTICE file distributed with
+@REM  this work for additional information regarding copyright ownership.
+@REM  The ASF licenses this file to You under the Apache License, Version 2.0
+@REM  (the License); you may not use this file except in compliance with
+@REM  the License.  You may obtain a copy of the License at
+@REM
+@REM  http://www.apache.org/licenses/LICENSE-2.0
+@REM
+@REM  Unless required by applicable law or agreed to in writing, software
+@REM  distributed under the License is distributed on an AS IS BASIS,
+@REM  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+@REM  See the License for the specific language governing permissions and
+@REM  limitations under the License.
 
-set DSDIR=%~dp0..
+if %OS% == Windows_NT setlocal
 
-%DSDIR%\python\python.exe %DSDIR%\apache-cassandra\bin\cqlsh %*
\ No newline at end of file
+python -V nul 21
+if ERRORLEVEL 1 goto err
+
+python %~dp0\cqlsh %*
+goto finally
+
+:err
+echo Can't detect Python version!
+
+:finally
+
+ENDLOCAL



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

2013-10-24 Thread dbrosius
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/8fbdc9f8
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8fbdc9f8
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8fbdc9f8

Branch: refs/heads/trunk
Commit: 8fbdc9f82d949ce2ec262defb5d41c4c47f96c81
Parents: 7233102 3dc4e65
Author: Dave Brosius dbros...@mebigfatguy.com
Authored: Fri Oct 25 00:19:53 2013 -0400
Committer: Dave Brosius dbros...@mebigfatguy.com
Committed: Fri Oct 25 00:19:53 2013 -0400

--
 bin/cqlsh.bat | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)
--




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

2013-10-24 Thread dbrosius
Merge branch 'cassandra-1.2' into cassandra-2.0


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

Branch: refs/heads/trunk
Commit: 3dc4e656370103ee616288a536f7758712b1ef91
Parents: 8bdd473 08a2272
Author: Dave Brosius dbros...@mebigfatguy.com
Authored: Fri Oct 25 00:19:11 2013 -0400
Committer: Dave Brosius dbros...@mebigfatguy.com
Committed: Fri Oct 25 00:19:11 2013 -0400

--
 bin/cqlsh.bat | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3dc4e656/bin/cqlsh.bat
--
diff --cc bin/cqlsh.bat
index 36023ea,a61df21..79adcff
--- a/bin/cqlsh.bat
+++ b/bin/cqlsh.bat
@@@ -1,21 -1,30 +1,33 @@@
  @REM
 -@REM  Licensed to the Apache Software Foundation (ASF) under one or more
 -@REM  contributor license agreements.  See the NOTICE file distributed with
 -@REM  this work for additional information regarding copyright ownership.
 -@REM  The ASF licenses this file to You under the Apache License, Version 2.0
 -@REM  (the License); you may not use this file except in compliance with
 -@REM  the License.  You may obtain a copy of the License at
 +@REM Licensed to the Apache Software Foundation (ASF) under one or more
 +@REM contributor license agreements. See the NOTICE file distributed with
 +@REM this work for additional information regarding copyright ownership.
 +@REM The ASF licenses this file to You under the Apache License, Version 2.0
 +@REM (the License); you may not use this file except in compliance with
 +@REM the License. You may obtain a copy of the License at
  @REM
 -@REM  http://www.apache.org/licenses/LICENSE-2.0
 +@REM http://www.apache.org/licenses/LICENSE-2.0
  @REM
 -@REM  Unless required by applicable law or agreed to in writing, software
 -@REM  distributed under the License is distributed on an AS IS BASIS,
 -@REM  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 -@REM  See the License for the specific language governing permissions and
 -@REM  limitations under the License.
 +@REM Unless required by applicable law or agreed to in writing, software
 +@REM distributed under the License is distributed on an AS IS BASIS,
 +@REM WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 +@REM See the License for the specific language governing permissions and
 +@REM limitations under the License.
 +
 +@echo off
  
- set DSDIR=%~dp0..
+ if %OS% == Windows_NT setlocal
+ 
+ python -V nul 21
+ if ERRORLEVEL 1 goto err
+ 
+ python %~dp0\cqlsh %*
+ goto finally
+ 
+ :err
+ echo Can't detect Python version!
+ 
+ :finally
+ 
+ ENDLOCAL
 +
- %DSDIR%\python\python.exe %DSDIR%\apache-cassandra\bin\cqlsh %*



[jira] [Commented] (CASSANDRA-6145) Include windows batch files for recently added shell commands (and some older ones)

2013-10-24 Thread Dave Brosius (JIRA)

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

Dave Brosius commented on CASSANDRA-6145:
-

thanks Mikhail, pushed patch to cassandra-1.2 as commit 
08a22729afedb53dfa988b3e2db34b7a743977de

 Include windows batch files for recently added shell commands (and some older 
 ones)
 ---

 Key: CASSANDRA-6145
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6145
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
 Environment: Windows
Reporter: Sven Delmas
Assignee: Sven Delmas
Priority: Trivial
 Fix For: 1.2.12

 Attachments: 6145-1.patch, 6145.patch, 
 cassandra-2.0-6145-cqlsh.bat.patch


 - cassandra-shuffle.bat seems very different than the ones already there. As 
 far as I can tell the differences are cosmetic, so I consolidate that.
 - cassandra-stress.bat
 - cassandra-stressd.bat
 - cqlsh.bat
 - debug-cql.bat
 - sstableloader.bat
 - sstablemetadata.bat
 - sstablescrub.bat
 - sstablesplit.bat
 - sstableupgrade.bat
 Not all files apply to all branches, but I figure I better include all the 
 ones I have.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


git commit: use junit assertions for unit tests over java asserts

2013-10-24 Thread dbrosius
Updated Branches:
  refs/heads/trunk 8fbdc9f82 - 2faac19e1


use junit assertions for unit tests over java asserts


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

Branch: refs/heads/trunk
Commit: 2faac19e1746d179c04596cb6885d1cb52663e77
Parents: 8fbdc9f
Author: Dave Brosius dbros...@mebigfatguy.com
Authored: Fri Oct 25 00:41:09 2013 -0400
Committer: Dave Brosius dbros...@mebigfatguy.com
Committed: Fri Oct 25 00:41:09 2013 -0400

--
 .../config/DatabaseDescriptorTest.java  | 29 +---
 1 file changed, 13 insertions(+), 16 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2faac19e/test/unit/org/apache/cassandra/config/DatabaseDescriptorTest.java
--
diff --git a/test/unit/org/apache/cassandra/config/DatabaseDescriptorTest.java 
b/test/unit/org/apache/cassandra/config/DatabaseDescriptorTest.java
index 7d1c82b..b954f39 100644
--- a/test/unit/org/apache/cassandra/config/DatabaseDescriptorTest.java
+++ b/test/unit/org/apache/cassandra/config/DatabaseDescriptorTest.java
@@ -31,14 +31,11 @@ import org.junit.runner.RunWith;
 
 import static org.junit.Assert.*;
 
-
-import java.io.IOException;
-
 @RunWith(OrderedJUnit4ClassRunner.class)
 public class DatabaseDescriptorTest
 {
 @Test
-public void testCFMetaDataSerialization() throws IOException, 
ConfigurationException, InvalidRequestException
+public void testCFMetaDataSerialization() throws ConfigurationException, 
InvalidRequestException
 {
 // test serialization of all defined test CFs.
 for (String keyspaceName : Schema.instance.getNonSystemKeyspaces())
@@ -46,21 +43,21 @@ public class DatabaseDescriptorTest
 for (CFMetaData cfm : 
Schema.instance.getKeyspaceMetaData(keyspaceName).values())
 {
 CFMetaData cfmDupe = CFMetaData.fromThrift(cfm.toThrift());
-assert cfmDupe != null;
-assert cfmDupe.equals(cfm);
+assertNotNull(cfmDupe);
+assertEquals(cfm, cfmDupe);
 }
 }
 }
 
 @Test
-public void testKSMetaDataSerialization() throws IOException, 
ConfigurationException
+public void testKSMetaDataSerialization() throws ConfigurationException
 {
 for (KSMetaData ksm : Schema.instance.getKeyspaceDefinitions())
 {
 // Not testing round-trip on the KsDef via serDe() because maps
 KSMetaData ksmDupe = KSMetaData.fromThrift(ksm.toThrift());
-assert ksmDupe != null;
-assert ksmDupe.equals(ksm);
+assertNotNull(ksmDupe);
+assertEquals(ksm, ksmDupe);
 }
 }
 
@@ -70,7 +67,7 @@ public class DatabaseDescriptorTest
 {
 SchemaLoader.cleanupAndLeaveDirs();
 DatabaseDescriptor.loadSchemas();
-assert Schema.instance.getNonSystemKeyspaces().size() == 0;
+assertEquals(0, Schema.instance.getNonSystemKeyspaces().size());
 
 Gossiper.instance.start((int)(System.currentTimeMillis() / 1000));
 
@@ -80,19 +77,19 @@ public class DatabaseDescriptorTest
 
MigrationManager.announceNewKeyspace(KSMetaData.testMetadata(ks0, 
SimpleStrategy.class, KSMetaData.optsWithRF(3)));
 
MigrationManager.announceNewKeyspace(KSMetaData.testMetadata(ks1, 
SimpleStrategy.class, KSMetaData.optsWithRF(3)));
 
-assert Schema.instance.getKSMetaData(ks0) != null;
-assert Schema.instance.getKSMetaData(ks1) != null;
+assertNotNull(Schema.instance.getKSMetaData(ks0));
+assertNotNull(Schema.instance.getKSMetaData(ks1));
 
 
Schema.instance.clearKeyspaceDefinition(Schema.instance.getKSMetaData(ks0));
 
Schema.instance.clearKeyspaceDefinition(Schema.instance.getKSMetaData(ks1));
 
-assert Schema.instance.getKSMetaData(ks0) == null;
-assert Schema.instance.getKSMetaData(ks1) == null;
+assertNull(Schema.instance.getKSMetaData(ks0));
+assertNull(Schema.instance.getKSMetaData(ks1));
 
 DatabaseDescriptor.loadSchemas();
 
-assert Schema.instance.getKSMetaData(ks0) != null;
-assert Schema.instance.getKSMetaData(ks1) != null;
+assertNotNull(Schema.instance.getKSMetaData(ks0));
+assertNotNull(Schema.instance.getKSMetaData(ks1));
 }
 finally
 {



[jira] [Commented] (CASSANDRA-6238) LOCAL_ONE doesn't work for SimpleStrategy

2013-10-24 Thread Jason Brown (JIRA)

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

Jason Brown commented on CASSANDRA-6238:


I used LOCAL_QUORUM's failing on non-NTS as my template I went by when making 
LOCAL_ONE only usable with NTS. I don't think it makes sense for the two CLs to 
behave differently: either they both should support non-NTS or not.  I'm not 
sure if I feel too strongly either way, but I'm more inclined to retain the 
current CL.LOCAL_* requiring NTS.

 LOCAL_ONE doesn't work for SimpleStrategy
 -

 Key: CASSANDRA-6238
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6238
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Alex Liu
Assignee: Alex Liu
 Fix For: 1.2.12, 2.0.3

 Attachments: 6238.txt, 6238-v2.txt


 LOCAL_ONE only works for NetworkTopologyStrategy which has DC specification. 
 Any other strategy fails.
 If there is no  DC specified in the strategy, we should treat LOCAL_ONE as ONE



--
This message was sent by Atlassian JIRA
(v6.1#6144)