git commit: Fix license
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
Updated Tags: refs/tags/2.0.2-tentative [deleted] b6147c1c7
Git Push Summary
Updated Tags: refs/tags/2.0.2-tentative [created] 22e67be8f
[Cassandra Wiki] Update of RunningCassandraInIDEA by JonathanEllis
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
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
[ 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
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
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
[ 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
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
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
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
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
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
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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
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
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
[ 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
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
[ 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)
[ 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
[ 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
[ 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
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
[ 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
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)
[ 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
[ 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
[ 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
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
[ 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
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
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
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
[ 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
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.
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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
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
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
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
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)
[ 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
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
[ 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)