date:20141030


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

Robert Stupp updated CASSANDRA-7813:

Attachment: 7813v4.txt

 Decide how to deal with conflict between native and user-defined functions
 --

 Key: CASSANDRA-7813
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
  Labels: cql
 Fix For: 3.0

 Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt


 We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in 
 3.0, user will be able to define new functions. Now, there is a very high 
 change that we will provide more native functions over-time (to be clear, I'm 
 not particularly for adding native functions for allthethings just because we 
 can, but it's clear that we should ultimately provide more than what we 
 have). Which begs the question: how do we want to deal with the problem of 
 adding a native function potentially breaking a previously defined 
 user-defined function?
 A priori I see the following options (maybe there is more?):
 # don't do anything specific, hoping that it won't happen often and consider 
 it a user problem if it does.
 # reserve a big number of names that we're hoping will cover all future need.
 # make native function and user-defined function syntactically distinct so it 
 cannot happen.
 I'm not a huge fan of solution 1). Solution 2) is actually what we did for 
 UDT but I think it's somewhat less practical here: there is so much types 
 that it makes sense to provide natively and so it wasn't too hard to come up 
 with a reasonably small list of types name to reserve just in case. This 
 feels a lot harder for functions to me.
 Which leaves solution 3). Since we already have the concept of namespaces for 
 functions, a simple idea would be to force user function to have namespace. 
 We could even allow that namespace to be empty as long as we force the 
 namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user 
 functions, but *not* {{foo}} which would be reserved for native function).



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

[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions


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

Robert Stupp updated CASSANDRA-7813:

Attachment: (was: 7813v4.txt)

 Decide how to deal with conflict between native and user-defined functions
 --

 Key: CASSANDRA-7813
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
  Labels: cql
 Fix For: 3.0

 Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt


 We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in 
 3.0, user will be able to define new functions. Now, there is a very high 
 change that we will provide more native functions over-time (to be clear, I'm 
 not particularly for adding native functions for allthethings just because we 
 can, but it's clear that we should ultimately provide more than what we 
 have). Which begs the question: how do we want to deal with the problem of 
 adding a native function potentially breaking a previously defined 
 user-defined function?
 A priori I see the following options (maybe there is more?):
 # don't do anything specific, hoping that it won't happen often and consider 
 it a user problem if it does.
 # reserve a big number of names that we're hoping will cover all future need.
 # make native function and user-defined function syntactically distinct so it 
 cannot happen.
 I'm not a huge fan of solution 1). Solution 2) is actually what we did for 
 UDT but I think it's somewhat less practical here: there is so much types 
 that it makes sense to provide natively and so it wasn't too hard to come up 
 with a reasonably small list of types name to reserve just in case. This 
 feels a lot harder for functions to me.
 Which leaves solution 3). Since we already have the concept of namespaces for 
 functions, a simple idea would be to force user function to have namespace. 
 We could even allow that namespace to be empty as long as we force the 
 namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user 
 functions, but *not* {{foo}} which would be reserved for native function).



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

[jira] [Commented] (CASSANDRA-8168) Require Java 8


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

Aleksey Yeschenko commented on CASSANDRA-8168:
--

Also +1 now, given the whole EOL situation.

I suggest we wait for another week or so, and unless there are any major 
objections, start using Java 8 features on trunk.

 Require Java 8
 --

 Key: CASSANDRA-8168
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8168
 Project: Cassandra
  Issue Type: Task
Reporter: T Jake Luciani
 Fix For: 3.0


 This is to discuss requiring Java 8 for version = 3.0  
 There are a couple big reasons for this.
 * Better support for complex async work  e.g (CASSANDRA-5239)
 http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html
 * Use Nashorn for Javascript UDFs CASSANDRA-7395



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

[jira] [Commented] (CASSANDRA-8168) Require Java 8


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

Robert Stupp commented on CASSANDRA-8168:
-

Just one issue (on OSX), which prevents clean shutdown : CASSANDRA-8220

 Require Java 8
 --

 Key: CASSANDRA-8168
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8168
 Project: Cassandra
  Issue Type: Task
Reporter: T Jake Luciani
 Fix For: 3.0


 This is to discuss requiring Java 8 for version = 3.0  
 There are a couple big reasons for this.
 * Better support for complex async work  e.g (CASSANDRA-5239)
 http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html
 * Use Nashorn for Javascript UDFs CASSANDRA-7395



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

[jira] [Assigned] (CASSANDRA-8168) Require Java 8


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

T Jake Luciani reassigned CASSANDRA-8168:
-

Assignee: T Jake Luciani

 Require Java 8
 --

 Key: CASSANDRA-8168
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8168
 Project: Cassandra
  Issue Type: Task
Reporter: T Jake Luciani
Assignee: T Jake Luciani
 Fix For: 3.0


 This is to discuss requiring Java 8 for version = 3.0  
 There are a couple big reasons for this.
 * Better support for complex async work  e.g (CASSANDRA-5239)
 http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html
 * Use Nashorn for Javascript UDFs CASSANDRA-7395



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

[jira] [Assigned] (CASSANDRA-8211) Overlapping sstables in L1+

2014-10-30 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson reassigned CASSANDRA-8211:
--

Assignee: Marcus Eriksson

 Overlapping sstables in L1+
 ---

 Key: CASSANDRA-8211
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8211
 Project: Cassandra
  Issue Type: Bug
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
 Fix For: 2.0.12


 Seems we have a bug that can create overlapping sstables in L1:
 {code}
 WARN [main] 2014-10-28 04:09:42,295 LeveledManifest.java (line 164) At level 
 2, SSTableReader(path='sstable') [DecoratedKey(2838397575996053472, 00
 10066059b210066059b210400100),
  DecoratedKey(5516674013223138308, 
 001000ff2d161000ff2d160
 00010400100)] overlaps 
 SSTableReader(path='sstable') [DecoratedKey(2839992722300822584, 
 0010
 00229ad21000229ad210400100),
  DecoratedKey(5532836928694021724, 
 0010034b05a610034b05a6100
 000400100)].  This could be caused by a bug in 
 Cassandra 1.1.0 .. 1.1.3 or due to the fact that you have dropped sstables 
 from another node into the data directory. Sending back to L0.  If
  you didn't drop in sstables, and have not yet run scrub, you should do so 
 since you may also have rows out-of-order within an sstable
 {code}
 Which might manifest itself during compaction with this exception:
 {code}
 ERROR [CompactionExecutor:3152] 2014-10-28 00:24:06,134 CassandraDaemon.java 
 (line 199) Exception in thread Thread[CompactionExecutor:3152,1,main]
 java.lang.RuntimeException: Last written key 
 DecoratedKey(5516674013223138308, 
 001000ff2d161000ff2d1610400100)
  = current key DecoratedKey(2839992722300822584, 
 001000229ad21000229ad210400100)
  writing into sstable
 {code}
 since we use LeveledScanner when compacting (the backing sstable scanner 
 might go beyond the start of the next sstable scanner)



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

svn commit: r6955 [1/4] - in /release/cassandra: ./ 1.2.19/ 2.0.11/ 2.1.1/ debian/ debian/dists/ debian/dists/06x/ debian/dists/06x/main/ debian/dists/06x/main/binary-amd64/ debian/dists/06x/main/bina

Author: jake
Date: Thu Oct 30 13:29:38 2014
New Revision: 6955

Log:
initial commit

Added:
release/cassandra/1.2.19/
release/cassandra/1.2.19/apache-cassandra-1.2.19-bin.tar.gz   (with props)
release/cassandra/1.2.19/apache-cassandra-1.2.19-bin.tar.gz.asc   (with 
props)
release/cassandra/1.2.19/apache-cassandra-1.2.19-bin.tar.gz.asc.md5
release/cassandra/1.2.19/apache-cassandra-1.2.19-bin.tar.gz.asc.sha1
release/cassandra/1.2.19/apache-cassandra-1.2.19-bin.tar.gz.md5
release/cassandra/1.2.19/apache-cassandra-1.2.19-bin.tar.gz.sha1
release/cassandra/1.2.19/apache-cassandra-1.2.19-src.tar.gz   (with props)
release/cassandra/1.2.19/apache-cassandra-1.2.19-src.tar.gz.asc   (with 
props)
release/cassandra/1.2.19/apache-cassandra-1.2.19-src.tar.gz.asc.md5
release/cassandra/1.2.19/apache-cassandra-1.2.19-src.tar.gz.asc.sha1
release/cassandra/1.2.19/apache-cassandra-1.2.19-src.tar.gz.md5
release/cassandra/1.2.19/apache-cassandra-1.2.19-src.tar.gz.sha1
release/cassandra/2.0.11/
release/cassandra/2.0.11/apache-cassandra-2.0.11-bin.tar.gz   (with props)
release/cassandra/2.0.11/apache-cassandra-2.0.11-bin.tar.gz.asc   (with 
props)
release/cassandra/2.0.11/apache-cassandra-2.0.11-bin.tar.gz.asc.md5
release/cassandra/2.0.11/apache-cassandra-2.0.11-bin.tar.gz.asc.sha1
release/cassandra/2.0.11/apache-cassandra-2.0.11-bin.tar.gz.md5
release/cassandra/2.0.11/apache-cassandra-2.0.11-bin.tar.gz.sha1
release/cassandra/2.0.11/apache-cassandra-2.0.11-src.tar.gz   (with props)
release/cassandra/2.0.11/apache-cassandra-2.0.11-src.tar.gz.asc   (with 
props)
release/cassandra/2.0.11/apache-cassandra-2.0.11-src.tar.gz.asc.md5
release/cassandra/2.0.11/apache-cassandra-2.0.11-src.tar.gz.asc.sha1
release/cassandra/2.0.11/apache-cassandra-2.0.11-src.tar.gz.md5
release/cassandra/2.0.11/apache-cassandra-2.0.11-src.tar.gz.sha1
release/cassandra/2.1.1/
release/cassandra/2.1.1/apache-cassandra-2.1.1-bin.tar.gz   (with props)
release/cassandra/2.1.1/apache-cassandra-2.1.1-bin.tar.gz.asc   (with props)
release/cassandra/2.1.1/apache-cassandra-2.1.1-bin.tar.gz.asc.md5
release/cassandra/2.1.1/apache-cassandra-2.1.1-bin.tar.gz.asc.sha1
release/cassandra/2.1.1/apache-cassandra-2.1.1-bin.tar.gz.md5
release/cassandra/2.1.1/apache-cassandra-2.1.1-bin.tar.gz.sha1
release/cassandra/2.1.1/apache-cassandra-2.1.1-src.tar.gz   (with props)
release/cassandra/2.1.1/apache-cassandra-2.1.1-src.tar.gz.asc   (with props)
release/cassandra/2.1.1/apache-cassandra-2.1.1-src.tar.gz.asc.md5
release/cassandra/2.1.1/apache-cassandra-2.1.1-src.tar.gz.asc.sha1
release/cassandra/2.1.1/apache-cassandra-2.1.1-src.tar.gz.md5
release/cassandra/2.1.1/apache-cassandra-2.1.1-src.tar.gz.sha1
release/cassandra/KEYS
release/cassandra/debian/
release/cassandra/debian/.htaccess
release/cassandra/debian/dists/
release/cassandra/debian/dists/06x/
release/cassandra/debian/dists/06x/InRelease
release/cassandra/debian/dists/06x/Release
release/cassandra/debian/dists/06x/Release.gpg   (with props)
release/cassandra/debian/dists/06x/main/
release/cassandra/debian/dists/06x/main/binary-amd64/
release/cassandra/debian/dists/06x/main/binary-amd64/Packages
release/cassandra/debian/dists/06x/main/binary-amd64/Packages.gz   (with 
props)
release/cassandra/debian/dists/06x/main/binary-amd64/Release
release/cassandra/debian/dists/06x/main/binary-i386/
release/cassandra/debian/dists/06x/main/binary-i386/Packages
release/cassandra/debian/dists/06x/main/binary-i386/Packages.gz   (with 
props)
release/cassandra/debian/dists/06x/main/binary-i386/Release
release/cassandra/debian/dists/06x/main/source/
release/cassandra/debian/dists/06x/main/source/Release
release/cassandra/debian/dists/06x/main/source/Sources.gz   (with props)
release/cassandra/debian/dists/07x/
release/cassandra/debian/dists/07x/InRelease
release/cassandra/debian/dists/07x/Release
release/cassandra/debian/dists/07x/Release.gpg   (with props)
release/cassandra/debian/dists/07x/main/
release/cassandra/debian/dists/07x/main/binary-amd64/
release/cassandra/debian/dists/07x/main/binary-amd64/Packages
release/cassandra/debian/dists/07x/main/binary-amd64/Packages.gz   (with 
props)
release/cassandra/debian/dists/07x/main/binary-amd64/Release
release/cassandra/debian/dists/07x/main/binary-i386/
release/cassandra/debian/dists/07x/main/binary-i386/Packages
release/cassandra/debian/dists/07x/main/binary-i386/Packages.gz   (with 
props)
release/cassandra/debian/dists/07x/main/binary-i386/Release
release/cassandra/debian/dists/07x/main/source/
release/cassandra/debian/dists/07x/main/source/Release
release/cassandra/debian/dists/07x/main/source/Sources.gz   (with props)
release/cassandra/debian/dists/08x/

svn commit: r6955 [3/4] - in /release/cassandra: ./ 1.2.19/ 2.0.11/ 2.1.1/ debian/ debian/dists/ debian/dists/06x/ debian/dists/06x/main/ debian/dists/06x/main/binary-amd64/ debian/dists/06x/main/bina

Added: release/cassandra/debian/.htaccess
==
--- release/cassandra/debian/.htaccess (added)
+++ release/cassandra/debian/.htaccess Thu Oct 30 13:29:38 2014
@@ -0,0 +1 @@
+RedirectMatch ^/~eevans/debian(.*) 
http://wiki.apache.org/cassandra/DebianPackaging

Added: release/cassandra/debian/dists/06x/InRelease
==
--- release/cassandra/debian/dists/06x/InRelease (added)
+++ release/cassandra/debian/dists/06x/InRelease Thu Oct 30 13:29:38 2014
@@ -0,0 +1,51 @@
+-BEGIN PGP SIGNED MESSAGE-
+Hash: SHA1
+
+Origin: Unofficial Cassandra Packages
+Label: Unofficial Cassandra Packages
+Codename: 06x
+Date: Tue, 16 Sep 2014 10:22:45 UTC
+Architectures: i386 amd64
+Components: main
+Description: Cassandra APT Repository
+MD5Sum:
+ 80abc38cc7abff97f00be2545464cfac 686 main/binary-i386/Packages
+ fac0900139d2ef42a32ac963ea6b439a 467 main/binary-i386/Packages.gz
+ 3214ca2c0fb908da64d0c82cedf49fec 148 main/binary-i386/Release
+ 80abc38cc7abff97f00be2545464cfac 686 main/binary-amd64/Packages
+ fac0900139d2ef42a32ac963ea6b439a 467 main/binary-amd64/Packages.gz
+ 37f612d4cf34c75e4ee8424f6fa711ea 149 main/binary-amd64/Release
+ d41d8cd98f00b204e9800998ecf8427e 0 main/source/Sources
+ 7029066c27ac6f5ef18d660d5741979a 20 main/source/Sources.gz
+ 5aa47f19dcecef15ff3b353cf85bfb29 150 main/source/Release
+SHA1:
+ 0ffba4c2de106cb71df5754e51c45a1676734d72 686 main/binary-i386/Packages
+ 90e29eac067e12ce492d0950b118dbb46ba05da3 467 main/binary-i386/Packages.gz
+ f49b67a648ccf6c6e4f96e003f61b089df0f54ed 148 main/binary-i386/Release
+ 0ffba4c2de106cb71df5754e51c45a1676734d72 686 main/binary-amd64/Packages
+ 90e29eac067e12ce492d0950b118dbb46ba05da3 467 main/binary-amd64/Packages.gz
+ ea578b501d3ecec83c2200c2bcebf172fa3efe98 149 main/binary-amd64/Release
+ da39a3ee5e6b4b0d3255bfef95601890afd80709 0 main/source/Sources
+ 46c6643f07aa7f6bfe7118de926b86defc5087c4 20 main/source/Sources.gz
+ 268c44a9381bbfbe1ca79f1a6836b205ecb07f79 150 main/source/Release
+SHA256:
+ 1a32883f75ad77cc057ea510e61301949f0955bbd840689369f58b5182f520fc 686 
main/binary-i386/Packages
+ 06431d4b487b49a8edf36b93af21440f7e092c4c69483829c9f17a286ddffb81 467 
main/binary-i386/Packages.gz
+ b9b8bd71a706df21065102d61b38de8513d0b796301e0b2df845e340347f06c7 148 
main/binary-i386/Release
+ 1a32883f75ad77cc057ea510e61301949f0955bbd840689369f58b5182f520fc 686 
main/binary-amd64/Packages
+ 06431d4b487b49a8edf36b93af21440f7e092c4c69483829c9f17a286ddffb81 467 
main/binary-amd64/Packages.gz
+ b29a345c4907522e3b159abe8f5886fc7eb54bce9d0d6ecbaded5445c3fab4a2 149 
main/binary-amd64/Release
+ e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 0 
main/source/Sources
+ 59869db34853933b239f1e2219cf7d431da006aa919635478511fabbfc8849d2 20 
main/source/Sources.gz
+ 88ec5d7fbffe60a98ac15a3e628afaad585c57275b6355481028d659d26bd30c 150 
main/source/Release
+-BEGIN PGP SIGNATURE-
+Version: GnuPG v1.4.12 (GNU/Linux)
+
+iQEcBAEBAgAGBQJUGA+DAAoJEEvXNqgrXBsA/dwIAJoc57743dIYl8SvT0n5lzKf
+U7Vr28J7sW3JVnSEHQCiCD2CUNgexQEUxtUpPWyrDXeRFM+MziNSjS+DTAT4D03l
+QU97heosW6Yx5WUItar0MlOT43xnhUTQ1vz6NIUKTobr129csM74F5XH7MscaQyF
+EQphMz97Y3vxIvh8przX4vl1M6p5JapdhizDBEZs0FkBiK4jFKZV8AGcz/NlYmY8
+Z1ripISJx5uEAbLTDd3gTfGOwL4kulm++Qlzp2m8tnLttPYjKnF2t4fYIq99p7OA
+PhEY/2Xd4L9YIGAXN46dCfnVwvtGp6qewDJcb4bA41zpVUp3U5FYdS1lrXkO8VU=
+=K27C
+-END PGP SIGNATURE-

Added: release/cassandra/debian/dists/06x/Release
==
--- release/cassandra/debian/dists/06x/Release (added)
+++ release/cassandra/debian/dists/06x/Release Thu Oct 30 13:29:38 2014
@@ -0,0 +1,37 @@
+Origin: Unofficial Cassandra Packages
+Label: Unofficial Cassandra Packages
+Codename: 06x
+Date: Tue, 16 Sep 2014 10:22:45 UTC
+Architectures: i386 amd64
+Components: main
+Description: Cassandra APT Repository
+MD5Sum:
+ 80abc38cc7abff97f00be2545464cfac 686 main/binary-i386/Packages
+ fac0900139d2ef42a32ac963ea6b439a 467 main/binary-i386/Packages.gz
+ 3214ca2c0fb908da64d0c82cedf49fec 148 main/binary-i386/Release
+ 80abc38cc7abff97f00be2545464cfac 686 main/binary-amd64/Packages
+ fac0900139d2ef42a32ac963ea6b439a 467 main/binary-amd64/Packages.gz
+ 37f612d4cf34c75e4ee8424f6fa711ea 149 main/binary-amd64/Release
+ d41d8cd98f00b204e9800998ecf8427e 0 main/source/Sources
+ 7029066c27ac6f5ef18d660d5741979a 20 main/source/Sources.gz
+ 5aa47f19dcecef15ff3b353cf85bfb29 150 main/source/Release
+SHA1:
+ 0ffba4c2de106cb71df5754e51c45a1676734d72 686 main/binary-i386/Packages
+ 90e29eac067e12ce492d0950b118dbb46ba05da3 467 main/binary-i386/Packages.gz
+ f49b67a648ccf6c6e4f96e003f61b089df0f54ed 148 main/binary-i386/Release
+ 0ffba4c2de106cb71df5754e51c45a1676734d72 686 main/binary-amd64/Packages
+ 90e29eac067e12ce492d0950b118dbb46ba05da3 467 main/binary-amd64/Packages.gz
+ ea578b501d3ecec83c2200c2bcebf172fa3efe98 149

svn commit: r6955 [2/4] - in /release/cassandra: ./ 1.2.19/ 2.0.11/ 2.1.1/ debian/ debian/dists/ debian/dists/06x/ debian/dists/06x/main/ debian/dists/06x/main/binary-amd64/ debian/dists/06x/main/bina

Added: release/cassandra/KEYS
==
--- release/cassandra/KEYS (added)
+++ release/cassandra/KEYS Thu Oct 30 13:29:38 2014
@@ -0,0 +1,3492 @@
+This file contains the PGP keys of various developers.
+
+Users: pgp  KEYS
+   gpg --import KEYS
+Developers: 
+pgp -kxa your name and append it to this file.
+(pgpk -ll your name  pgpk -xa your name)  this file.
+(gpg --list-sigs your name
+  gpg --armor --export your name)  this file.
+
+pub   1024D/F2833C93 2004-01-18
+uid  Eric Evans eev...@sym-link.com
+sig 3F2833C93 2009-05-12  Eric Evans eev...@sym-link.com
+sig  551BE447 2005-07-19  Torsten Landschoff tors...@debian.org
+sig  52B7487E 2005-07-15  Steinar H. Gunderson se...@debian.org
+sig  5F6D8015 2005-07-15  Kalle Kivimaa kil...@killeri.net
+sig  1880283C 2005-07-20  Anibal Monsalve Salazar ani...@debian.org
+sig  3DE9A7CA 2005-07-16  [User ID not found]
+sig  258D8781 2005-07-16  Michael Bramer michael.bra...@credativ.de
+sig  1CF2D62A 2005-07-19  [User ID not found]
+sig  7355FAFF 2005-07-19  [User ID not found]
+sig  DA6AE621 2005-07-20  Adeodato SimÃ³ d...@net.com.org.es
+sig  330C4A75 2005-07-19  Martin F. Krafft m...@martin-krafft.net
+sig  4743206C 2005-07-15  Joachim Breitner m...@joachim-breitner.de
+sig  5D64F870 2005-07-15  Martin Zobel-Helas zo...@debian.org
+sig  5ED7198E 2005-07-16  [User ID not found]
+sig  8B8D7663 2005-07-16  Andreas Metzler (private key) 
ametz...@downhill.at.eu.org
+sig  78446F26 2005-07-16  Joshua Kwan jo...@triplehelix.org
+sig  534584E8 2005-07-16  Antti-Juhani Kaijanaho a...@debian.org
+sig  B0D904CF 2005-07-16  [User ID not found]
+sig  C0143D2D 2005-07-17  Christian Perrier 
bubu...@kheops.homeunix.org
+sig  E06B3F97 2005-07-17  Mattias Nordstrom 
mattias.nordst...@sysnor.fi
+sig  F0D7D44A 2005-07-17  Jimmy Kaplowitz ji...@kaplowitz.org
+sig  736C856E 2005-07-18  [User ID not found]
+sig  1E880A84 2005-07-18  Frans Pop (Debian) elen...@planet.nl
+sig  39A8CCE2 2005-07-18  Eugeniy Meshcheryakov eu...@debian.org
+sig  808D0FD0 2005-07-19  Don Armstrong d...@donarmstrong.com
+sig 294C09C7F 2005-07-19  Peter Palfrader
+sig  E02FEF11 2005-07-19  Robert JÃ¶rdens jord...@debian.org
+sig  7984A4FD 2005-07-19  [User ID not found]
+sig  F2CF01A8 2005-07-20  Bdale Garbee bd...@gag.com
+sig  149CDDB2 2005-07-21  [User ID not found]
+sig  CDB6DBEC 2005-07-21  [User ID not found]
+sig  45F3FBF9 2005-07-21  John Lightsey light...@debian.org
+sig  307D56ED 2005-07-21  NoÃ¨l KÃ¶the n...@debian.org
+sig 274A8390A 2005-07-22  [User ID not found]
+sig  C671257D 2005-07-22  David Moreno da...@axiombox.com
+sig  67209BDE 2005-07-22  Aigars Mahinovs aigar...@debian.org
+sig  90788E11 2005-07-22  Jose Carlos Garcia Sogo js...@debian.org
+sig  3CC88C09 2005-07-23  Fumitoshi UKAI u...@debian.org
+sig  2FA3BC2D 2005-07-24  [User ID not found]
+sig  66F854B2 2005-07-24  [User ID not found]
+sig  F1BCDB73 2005-07-19  Aurelien Jarno aurel...@aurel32.net
+sig  EFAA3331 2005-07-26  Dennis Stampfer se...@debian.org
+sig  294260F6 2005-07-26  [User ID not found]
+sig  E19F188E 2005-07-26  Troy Heber troy.he...@hp.com
+sig  67D8E867 2005-07-26  [User ID not found]
+sig  1BF8DE0F 2005-07-27  Roland Stigge sti...@antcom.de
+sig  1228EB75 2005-07-16  [User ID not found]
+sig  0F30A7D6 2005-07-16  [User ID not found]
+sig  E8DACF5C 2005-07-16  [User ID not found]
+sig  14D4060B 2005-07-16  Sven Mueller deb...@incase.de
+sig  F93F813B 2005-07-17  [User ID not found]
+sig  EA7CF5AD 2005-07-17  Nicolas FRANÃOIS nek...@debian.org
+sig  29499F61 2005-07-17  Sam Hocevar s...@zoy.org
+sig  88F88F8F 2005-07-17  [User ID not found]
+sig  882A6C4B 2005-07-18  [User ID not found]
+sig  873F25F1 2005-07-18  [User ID not found]
+sig  EA2D2C41 2005-07-18  Mattia Dongili malat...@linux.it
+sig  964199E2 2005-07-22  Fabian Fagerholm fa...@paniq.net
+sig  26CF837C 2005-07-22  [User ID not found]
+sig 310731977 2005-07-16  [User ID not found]
+sig 3A30EC22B 2005-07-16  [User ID not found]
+sig 35E0577F2 2005-07-18  Martin Pitt mar...@piware.de
+sig  37EDA93E 2005-07-16  [User ID not found]
+sig 29FE8D504 2005-07-21  Tomas Fasth to...@debian.org
+sig 253805746 2005-07-15  [User ID not found]
+sig 388C7C1F7 2005-07-16  Steve McIntyre st...@einval.com
+sig  0813569F 2005-07-29  Jeroen van Wolffelaar jer...@wolffelaar.nl
+sig  7244970B 2005-07-29  Kurt Roeckx

svn commit: r6955 [4/4] - in /release/cassandra: ./ 1.2.19/ 2.0.11/ 2.1.1/ debian/ debian/dists/ debian/dists/06x/ debian/dists/06x/main/ debian/dists/06x/main/binary-amd64/ debian/dists/06x/main/bina

Added: release/cassandra/debian/dists/sid/InRelease
==
--- release/cassandra/debian/dists/sid/InRelease (added)
+++ release/cassandra/debian/dists/sid/InRelease Thu Oct 30 13:29:38 2014
@@ -0,0 +1,58 @@
+-BEGIN PGP SIGNED MESSAGE-
+Hash: SHA1
+
+Origin: Unofficial Cassandra Packages
+Label: Unofficial Cassandra Packages
+Suite: unstable
+Codename: sid
+Date: Wed, 17 Sep 2014 20:39:01 UTC
+Architectures: i386 amd64
+Components: main
+Description: Cassandra APT Repository
+MD5Sum:
+ d41d8cd98f00b204e9800998ecf8427e 0 main/binary-i386/Packages
+ 7029066c27ac6f5ef18d660d5741979a 20 main/binary-i386/Packages.gz
+ 1d4960e3f6844df30388cba7c197f241 166 main/binary-i386/Release
+ d41d8cd98f00b204e9800998ecf8427e 0 main/binary-amd64/Packages
+ 7029066c27ac6f5ef18d660d5741979a 20 main/binary-amd64/Packages.gz
+ baaad13af3f2f0d396203e12b97339ea 167 main/binary-amd64/Release
+ d41d8cd98f00b204e9800998ecf8427e 0 main/source/Sources
+ 7029066c27ac6f5ef18d660d5741979a 20 main/source/Sources.gz
+ 577d02121082560d1b0a703ed691a3af 168 main/source/Release
+SHA1:
+ da39a3ee5e6b4b0d3255bfef95601890afd80709 0 main/binary-i386/Packages
+ 46c6643f07aa7f6bfe7118de926b86defc5087c4 20 main/binary-i386/Packages.gz
+ 19c51cd55497480aa87460b1c2d6c908349d077c 166 main/binary-i386/Release
+ da39a3ee5e6b4b0d3255bfef95601890afd80709 0 main/binary-amd64/Packages
+ 46c6643f07aa7f6bfe7118de926b86defc5087c4 20 main/binary-amd64/Packages.gz
+ 7a0a672c75529f43268321e70137fc508da5837f 167 main/binary-amd64/Release
+ da39a3ee5e6b4b0d3255bfef95601890afd80709 0 main/source/Sources
+ 46c6643f07aa7f6bfe7118de926b86defc5087c4 20 main/source/Sources.gz
+ 0d7e9ad0c17e8ab8e6d64445c4732e00509fb29d 168 main/source/Release
+SHA256:
+ e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 0 
main/binary-i386/Packages
+ 59869db34853933b239f1e2219cf7d431da006aa919635478511fabbfc8849d2 20 
main/binary-i386/Packages.gz
+ c237c16caf57e6aff94b7fed9495b8ea873564671902c7e13700d0c5d8ba7581 166 
main/binary-i386/Release
+ e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 0 
main/binary-amd64/Packages
+ 59869db34853933b239f1e2219cf7d431da006aa919635478511fabbfc8849d2 20 
main/binary-amd64/Packages.gz
+ 2597a2eff79905ed97885fea0f4959c2b820b63dac259ed665a47229ee2d881f 167 
main/binary-amd64/Release
+ e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 0 
main/source/Sources
+ 59869db34853933b239f1e2219cf7d431da006aa919635478511fabbfc8849d2 20 
main/source/Sources.gz
+ 8cc604fb0f2a3da318d10bfb0ce596e0e6736e7dbe8d204e9b75c71b46f053a4 168 
main/source/Release
+-BEGIN PGP SIGNATURE-
+Version: GnuPG v1
+
+iQIcBAEBAgAGBQJUGfFnAAoJEHSdbuwDU7Es1WYQAI85TM3FARy4/EpHod8O/e4Y
+Q+ioVpVOW2DvZ9ihaTDEeDcJRcCQkroEcjcAe0oKZTj6iGouwvXd1PRhl/o8szUb
+EBWgOfXnaAIWYRpX58XjVznq4KwEraXkgF+PmT2Nq30v/sKpsBp/jgnYxW9cYRpa
+C+nioJwtOXQjBOMV8VpJS8pq5gNwdfQUgQsZ6jpys6K/RUM0kDeSuHl44JDcgpQZ
+VQCaUzZYtjEEZ8jg/GfvRyWTtLnreQYgXy45J2ZzvODL5h7SOMkiWTHjq50/h/eW
+7iXPpAJyiCG6ioOTws7KAT7+SXu4Zd2cM10r2dUelxFNIgjKGy4IidaeJnRlljf7
+kRDCYnMn5OznA13Eu8IH69fv6PphmMkt/Lhmr+DiIjVsZ5PKnMYXCwI06GrsMBFm
+MMheYaOypR8WWYxof3vP6YqALUAE1ZclWTuxiwhV2uP1ui2ddo8UDHbDrGA7BX+R
+g4F7TUNiTbRTBeKz6uKvCtEmw+t/9zeHBo1pbGW7rvW4UD5kbS6+zKBJ1ZzXTpRZ
+sRF9bONQUrYsuL7Qlz78VBOP/z+tc34n0GFoDScF5lr2Pz3wQ8kfesLKt9morS3A
+nouitGSMo5VKhNIaBZyt/nCjgbUPEe2uO6QQaYtkHtFqM32zB1I/cFmnN2jVCHQk
+t4RC6tXk1II/P6mIltFq
+=SnRB
+-END PGP SIGNATURE-

Added: release/cassandra/debian/dists/sid/Release
==
--- release/cassandra/debian/dists/sid/Release (added)
+++ release/cassandra/debian/dists/sid/Release Thu Oct 30 13:29:38 2014
@@ -0,0 +1,38 @@
+Origin: Unofficial Cassandra Packages
+Label: Unofficial Cassandra Packages
+Suite: unstable
+Codename: sid
+Date: Wed, 17 Sep 2014 20:39:01 UTC
+Architectures: i386 amd64
+Components: main
+Description: Cassandra APT Repository
+MD5Sum:
+ d41d8cd98f00b204e9800998ecf8427e 0 main/binary-i386/Packages
+ 7029066c27ac6f5ef18d660d5741979a 20 main/binary-i386/Packages.gz
+ 1d4960e3f6844df30388cba7c197f241 166 main/binary-i386/Release
+ d41d8cd98f00b204e9800998ecf8427e 0 main/binary-amd64/Packages
+ 7029066c27ac6f5ef18d660d5741979a 20 main/binary-amd64/Packages.gz
+ baaad13af3f2f0d396203e12b97339ea 167 main/binary-amd64/Release
+ d41d8cd98f00b204e9800998ecf8427e 0 main/source/Sources
+ 7029066c27ac6f5ef18d660d5741979a 20 main/source/Sources.gz
+ 577d02121082560d1b0a703ed691a3af 168 main/source/Release
+SHA1:
+ da39a3ee5e6b4b0d3255bfef95601890afd80709 0 main/binary-i386/Packages
+ 46c6643f07aa7f6bfe7118de926b86defc5087c4 20 main/binary-i386/Packages.gz
+ 19c51cd55497480aa87460b1c2d6c908349d077c 166 main/binary-i386/Release
+ da39a3ee5e6b4b0d3255bfef95601890afd80709 0 main/binary-amd64/Packages
+ 46c6643f07aa7f6bfe7118de926b86defc5087c4 20 main/binary-amd64/Packages.gz
+ 7a0a672c75529f43268321e70137fc508da5837f 167

[jira] [Updated] (CASSANDRA-7463) Update CQLSSTableWriter to allow parallel writing of SSTables on the same table within the same JVM

2014-10-30 Thread Carl Yeksigian (JIRA)


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

Carl Yeksigian updated CASSANDRA-7463:
--
Attachment: 7463-trunk.txt
7463-2.1.txt

Rebased for 2.1 and trunk.

 Update CQLSSTableWriter to allow parallel writing of SSTables on the same 
 table within the same JVM
 ---

 Key: CASSANDRA-7463
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7463
 Project: Cassandra
  Issue Type: Improvement
Reporter: Johnny Miller
Assignee: Carl Yeksigian
 Fix For: 2.0.12

 Attachments: 7463-2.0-v3.txt, 7463-2.1.txt, 7463-trunk.txt, 
 7463-v2.txt, 7463.patch


 Currently it is not possible to programatically write multiple SSTables for 
 the same table in parallel using the CQLSSTableWriter. This is quite a 
 limitation and the workaround of attempting to do this in a separate JVM is 
 not a great solution.
 See: 
 http://stackoverflow.com/questions/24396902/using-cqlsstablewriter-concurrently



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

[jira] [Resolved] (CASSANDRA-8209) Cassandra crashes when running on OpenJDK8 update 40


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

Michael Shuler resolved CASSANDRA-8209.
---
Resolution: Not a Problem

Not a problem, yet.

If, for instance, Ubuntu releases a version in a stable LTS release that 
includes this sort of breakage, please, open a ticket with those version 
details.

 Cassandra crashes when running on OpenJDK8 update 40
 

 Key: CASSANDRA-8209
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jaroslav Kamenik

 It seems that problem is change made in update 40 - 
 https://bugs.openjdk.java.net/browse/JDK-6642881
 result is:
 java.lang.SecurityException: Cannot make java.lang.Class.classLoader 
 accessible
 at 
 java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) 
 ~[na:1.8.0_40-ea]
 at 
 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) 
 ~[na:1.8.0_40-ea]
 at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) 
 ~[jamm-0.2.6.jar:na]
 at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) 
 ~[jamm-0.2.6.jar:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
 [na:1.8.0_40-ea]
 at 
 org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
 [apache-cassandra-2.1.1.jar:2.1.1]
 at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea]



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

[jira] [Comment Edited] (CASSANDRA-8209) Cassandra crashes when running on OpenJDK8 update 40


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

Michael Shuler edited comment on CASSANDRA-8209 at 10/30/14 2:45 PM:
-

Not a problem, yet.

If, for instance, Ubuntu releases a version in a stable LTS release that 
includes this sort of breakage, please, open a ticket with those version 
details.

I really appreciate the notification and testing out upstream JDK functionality 
- that's great. The fact that JDK bug exists, I hope that would get fixed 
upstream and never make it to a JDK release. That would be the correct place to 
fix this.


was (Author: mshuler):
Not a problem, yet.

If, for instance, Ubuntu releases a version in a stable LTS release that 
includes this sort of breakage, please, open a ticket with those version 
details.

 Cassandra crashes when running on OpenJDK8 update 40
 

 Key: CASSANDRA-8209
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jaroslav Kamenik

 It seems that problem is change made in update 40 - 
 https://bugs.openjdk.java.net/browse/JDK-6642881
 result is:
 java.lang.SecurityException: Cannot make java.lang.Class.classLoader 
 accessible
 at 
 java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) 
 ~[na:1.8.0_40-ea]
 at 
 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) 
 ~[na:1.8.0_40-ea]
 at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) 
 ~[jamm-0.2.6.jar:na]
 at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) 
 ~[jamm-0.2.6.jar:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
 [na:1.8.0_40-ea]
 at 
 org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
 [apache-cassandra-2.1.1.jar:2.1.1]
 at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea]



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

[jira] [Updated] (CASSANDRA-8222) Unable to connect to any server with cqlsh


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

Philip Thompson updated CASSANDRA-8222:
---
Labels: cqlsh  (was: )

 Unable to connect to any server with cqlsh
 

 Key: CASSANDRA-8222
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8222
 Project: Cassandra
  Issue Type: Bug
 Environment: java -version
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 python --version
 Python 2.7.8
Reporter: RADOMIRS CIRSKIS
  Labels: cqlsh

 I was going through the http://wiki.apache.org/cassandra/GettingStarted
 1. Installed cassandra
 2.  run cassandra: bin/cassandra -f
 3. in another terminal attempt to run cqlsh: cqlsh
 4. also I have tried explicitly: cqlsh 127.0.0.1 9042
 5. it produces a message:
 {noformat}
 Connection error: ('Unable to connect to any servers', {'127.0.0.1': 
 AttributeError('module' object has no attribute 'loads',)})
 {noformat}
 Cassandra is running and listening on the port 9042:
 {noformat}
 ...
 INFO  03:36:08 Using Netty Version: 
 [netty-buffer=netty-buffer-4.0.23.Final.208198c, 
 netty-codec=netty-codec-4.0.23.Final.208198c, 
 netty-codec-http=netty-codec-http-4.0.23.Final.208198c, 
 netty-codec-socks=netty-codec-socks-4.0.23.Final.208198c, 
 netty-common=netty-common-4.0.23.Final.208198c, 
 netty-handler=netty-handler-4.0.23.Final.208198c, 
 netty-transport=netty-transport-4.0.23.Final.208198c, 
 netty-transport-rxtx=netty-transport-rxtx-4.0.23.Final.208198c, 
 netty-transport-sctp=netty-transport-sctp-4.0.23.Final.208198c, 
 netty-transport-udt=netty-transport-udt-4.0.23.Final.208198c]
 INFO  03:36:08 Starting listening for CQL clients on 
 localhost/127.0.0.1:9042...
 INFO  03:36:09 Binding thrift service to localhost/127.0.0.1:9160
 INFO  03:36:09 Listening for thrift clients...
 {noformat}



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

[jira] [Commented] (CASSANDRA-8222) Unable to connect to any server with cqlsh


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

Philip Thompson commented on CASSANDRA-8222:


What version of Cassandra are you running? And are you running the exact cqlsh 
that came with your Cassandra install?

 Unable to connect to any server with cqlsh
 

 Key: CASSANDRA-8222
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8222
 Project: Cassandra
  Issue Type: Bug
 Environment: java -version
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 python --version
 Python 2.7.8
Reporter: RADOMIRS CIRSKIS
  Labels: cqlsh

 I was going through the http://wiki.apache.org/cassandra/GettingStarted
 1. Installed cassandra
 2.  run cassandra: bin/cassandra -f
 3. in another terminal attempt to run cqlsh: cqlsh
 4. also I have tried explicitly: cqlsh 127.0.0.1 9042
 5. it produces a message:
 {noformat}
 Connection error: ('Unable to connect to any servers', {'127.0.0.1': 
 AttributeError('module' object has no attribute 'loads',)})
 {noformat}
 Cassandra is running and listening on the port 9042:
 {noformat}
 ...
 INFO  03:36:08 Using Netty Version: 
 [netty-buffer=netty-buffer-4.0.23.Final.208198c, 
 netty-codec=netty-codec-4.0.23.Final.208198c, 
 netty-codec-http=netty-codec-http-4.0.23.Final.208198c, 
 netty-codec-socks=netty-codec-socks-4.0.23.Final.208198c, 
 netty-common=netty-common-4.0.23.Final.208198c, 
 netty-handler=netty-handler-4.0.23.Final.208198c, 
 netty-transport=netty-transport-4.0.23.Final.208198c, 
 netty-transport-rxtx=netty-transport-rxtx-4.0.23.Final.208198c, 
 netty-transport-sctp=netty-transport-sctp-4.0.23.Final.208198c, 
 netty-transport-udt=netty-transport-udt-4.0.23.Final.208198c]
 INFO  03:36:08 Starting listening for CQL clients on 
 localhost/127.0.0.1:9042...
 INFO  03:36:09 Binding thrift service to localhost/127.0.0.1:9160
 INFO  03:36:09 Listening for thrift clients...
 {noformat}



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

[jira] [Commented] (CASSANDRA-7852) Refactor/document how we track live size

2014-10-30 Thread Yuki Morishita (JIRA)


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

Yuki Morishita commented on CASSANDRA-7852:
---

Commented: 
https://github.com/krummas/cassandra/commit/97497699d28d958a0835a15e4739a98d5455a9db#commitcomment-8370545

Other nits:

- unused imports on SSTableRewriter
- SSTableRewriterTest is throwing time out when run using ant on my machine, 
though it runs successfully when time out is not set.

 Refactor/document how we track live size
 

 Key: CASSANDRA-7852
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7852
 Project: Cassandra
  Issue Type: Improvement
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
Priority: Minor
 Fix For: 2.1.2


 The way we track live size of sstables etc is a bit confusing after we 
 introduced SSTableRewriter, we should probably try to refactor or atleast 
 document this



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

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

Merge branch 'cassandra-2.1' into trunk


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

Branch: refs/heads/trunk
Commit: c4c9303d213ab0996dc088dea8719c7880e57916
Parents: 030aa57 84bc49e
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 30 10:49:27 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 30 10:49:27 2014 -0500

--

--

[4/4] git commit: Update CQLSSTableWriter to allow parallel writing of SSTables on the same table within the same JVM

Update CQLSSTableWriter to allow parallel writing of SSTables on the same table 
within the same JVM

Patch by Carl Yeksigian, reviewed by Benjamin Lerer for CASSANDRA-7463


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

Branch: refs/heads/trunk
Commit: fbb6b8abfa359be3475ba55912d939096637b8f8
Parents: c4c9303
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 30 10:49:42 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 30 10:49:42 2014 -0500

--
 .../io/sstable/AbstractSSTableSimpleWriter.java | 12 ++-
 .../cassandra/io/sstable/CQLSSTableWriter.java  | 41 +
 .../io/sstable/CQLSSTableWriterTest.java| 93 
 3 files changed, 127 insertions(+), 19 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fbb6b8ab/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
--
diff --git 
a/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java 
b/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
index 11d6d5e..2854308 100644
--- a/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
@@ -24,6 +24,7 @@ import java.io.IOException;
 import java.nio.ByteBuffer;
 import java.util.HashSet;
 import java.util.Set;
+import java.util.concurrent.atomic.AtomicInteger;
 
 import org.apache.cassandra.config.CFMetaData;
 import org.apache.cassandra.config.DatabaseDescriptor;
@@ -45,6 +46,7 @@ public abstract class AbstractSSTableSimpleWriter implements 
Closeable
 protected ByteBuffer currentSuperColumn;
 protected final CounterId counterid = CounterId.generate();
 private SSTableFormat.Type formatType = 
DatabaseDescriptor.getSSTableFormat();
+protected static AtomicInteger generation = new AtomicInteger(0);
 
 
 public AbstractSSTableSimpleWriter(File directory, CFMetaData metadata, 
IPartitioner partitioner)
@@ -83,9 +85,15 @@ public abstract class AbstractSSTableSimpleWriter implements 
Closeable
 return false;
 }
 });
-int maxGen = 0;
+int maxGen = generation.getAndIncrement();
 for (Descriptor desc : existing)
-maxGen = Math.max(maxGen, desc.generation);
+{
+while (desc.generation  maxGen)
+{
+maxGen = generation.getAndIncrement();
+}
+}
+
 return new Descriptor(directory, keyspace, columnFamily, maxGen + 1, 
Descriptor.Type.TEMP, fmt).filenameFor(Component.DATA);
 }
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fbb6b8ab/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java 
b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
index f7d467e..d4b4eab 100644
--- a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
@@ -28,6 +28,7 @@ import java.util.List;
 import java.util.Map;
 
 import com.google.common.collect.ImmutableMap;
+import com.google.common.collect.Iterables;
 
 import org.apache.cassandra.cql3.statements.*;
 import org.apache.cassandra.cql3.*;
@@ -338,25 +339,31 @@ public class CQLSSTableWriter implements Closeable
 {
 try
 {
-this.schema = getStatement(schema, CreateTableStatement.class, 
CREATE TABLE).left.getCFMetaData().rebuild();
-
-// We need to register the keyspace/table metadata through 
Schema, otherwise we won't be able to properly
-// build the insert statement in using().
-if (Schema.instance.getKSMetaData(this.schema.ksName) == null)
-{
-KSMetaData ksm = KSMetaData.newKeyspace(this.schema.ksName,
-
AbstractReplicationStrategy.getClass(org.apache.cassandra.locator.SimpleStrategy),
-
ImmutableMap.of(replication_factor, 1),
-true,
-
Collections.singleton(this.schema));
-Schema.instance.load(ksm);
-}
-else if (Schema.instance.getCFMetaData(this.schema.ksName,

[2/4] git commit: Update CQLSSTableWriter to allow parallel writing of SSTables on the same table within the same JVM

Update CQLSSTableWriter to allow parallel writing of SSTables on the same table 
within the same JVM

Patch by Carl Yeksigian, reviewed by Benjamin Lerer for CASSANDRA-7463


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

Branch: refs/heads/trunk
Commit: 84bc49e900772b04cda4c21e48f23b84f0e0b2cd
Parents: bb8cc62
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 30 10:47:43 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 30 10:47:43 2014 -0500

--
 .../io/sstable/AbstractSSTableSimpleWriter.java | 12 ++-
 .../cassandra/io/sstable/CQLSSTableWriter.java  | 41 +
 .../io/sstable/CQLSSTableWriterTest.java| 93 
 3 files changed, 127 insertions(+), 19 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/84bc49e9/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
--
diff --git 
a/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java 
b/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
index f8999bf..67d160d 100644
--- a/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
@@ -24,6 +24,7 @@ import java.io.IOException;
 import java.nio.ByteBuffer;
 import java.util.HashSet;
 import java.util.Set;
+import java.util.concurrent.atomic.AtomicInteger;
 
 import org.apache.cassandra.config.CFMetaData;
 import org.apache.cassandra.config.DatabaseDescriptor;
@@ -43,6 +44,7 @@ public abstract class AbstractSSTableSimpleWriter implements 
Closeable
 protected ColumnFamily columnFamily;
 protected ByteBuffer currentSuperColumn;
 protected final CounterId counterid = CounterId.generate();
+protected static AtomicInteger generation = new AtomicInteger(0);
 
 public AbstractSSTableSimpleWriter(File directory, CFMetaData metadata, 
IPartitioner partitioner)
 {
@@ -81,9 +83,15 @@ public abstract class AbstractSSTableSimpleWriter implements 
Closeable
 return false;
 }
 });
-int maxGen = 0;
+int maxGen = generation.getAndIncrement();
 for (Descriptor desc : existing)
-maxGen = Math.max(maxGen, desc.generation);
+{
+while (desc.generation  maxGen)
+{
+maxGen = generation.getAndIncrement();
+}
+}
+
 return new Descriptor(directory, keyspace, columnFamily, maxGen + 1, 
Descriptor.Type.TEMP).filenameFor(Component.DATA);
 }
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/84bc49e9/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java 
b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
index bf4da24..f302599 100644
--- a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
@@ -28,6 +28,7 @@ import java.util.List;
 import java.util.Map;
 
 import com.google.common.collect.ImmutableMap;
+import com.google.common.collect.Iterables;
 
 import org.apache.cassandra.cql3.statements.*;
 import org.apache.cassandra.cql3.*;
@@ -335,25 +336,31 @@ public class CQLSSTableWriter implements Closeable
 {
 try
 {
-this.schema = getStatement(schema, CreateTableStatement.class, 
CREATE TABLE).left.getCFMetaData().rebuild();
-
-// We need to register the keyspace/table metadata through 
Schema, otherwise we won't be able to properly
-// build the insert statement in using().
-if (Schema.instance.getKSMetaData(this.schema.ksName) == null)
-{
-KSMetaData ksm = KSMetaData.newKeyspace(this.schema.ksName,
-
AbstractReplicationStrategy.getClass(org.apache.cassandra.locator.SimpleStrategy),
-
ImmutableMap.of(replication_factor, 1),
-true,
-
Collections.singleton(this.schema));
-Schema.instance.load(ksm);
-}
-else if (Schema.instance.getCFMetaData(this.schema.ksName, 
this.schema.cfName) == null)
+synchronized

[1/4] git commit: Update CQLSSTableWriter to allow parallel writing of SSTables on the same table within the same JVM

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 bb8cc6214 - 84bc49e90
  refs/heads/trunk 030aa57cd - fbb6b8abf


Update CQLSSTableWriter to allow parallel writing of SSTables on the same table 
within the same JVM

Patch by Carl Yeksigian, reviewed by Benjamin Lerer for CASSANDRA-7463


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

Branch: refs/heads/cassandra-2.1
Commit: 84bc49e900772b04cda4c21e48f23b84f0e0b2cd
Parents: bb8cc62
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 30 10:47:43 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 30 10:47:43 2014 -0500

--
 .../io/sstable/AbstractSSTableSimpleWriter.java | 12 ++-
 .../cassandra/io/sstable/CQLSSTableWriter.java  | 41 +
 .../io/sstable/CQLSSTableWriterTest.java| 93 
 3 files changed, 127 insertions(+), 19 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/84bc49e9/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
--
diff --git 
a/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java 
b/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
index f8999bf..67d160d 100644
--- a/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
@@ -24,6 +24,7 @@ import java.io.IOException;
 import java.nio.ByteBuffer;
 import java.util.HashSet;
 import java.util.Set;
+import java.util.concurrent.atomic.AtomicInteger;
 
 import org.apache.cassandra.config.CFMetaData;
 import org.apache.cassandra.config.DatabaseDescriptor;
@@ -43,6 +44,7 @@ public abstract class AbstractSSTableSimpleWriter implements 
Closeable
 protected ColumnFamily columnFamily;
 protected ByteBuffer currentSuperColumn;
 protected final CounterId counterid = CounterId.generate();
+protected static AtomicInteger generation = new AtomicInteger(0);
 
 public AbstractSSTableSimpleWriter(File directory, CFMetaData metadata, 
IPartitioner partitioner)
 {
@@ -81,9 +83,15 @@ public abstract class AbstractSSTableSimpleWriter implements 
Closeable
 return false;
 }
 });
-int maxGen = 0;
+int maxGen = generation.getAndIncrement();
 for (Descriptor desc : existing)
-maxGen = Math.max(maxGen, desc.generation);
+{
+while (desc.generation  maxGen)
+{
+maxGen = generation.getAndIncrement();
+}
+}
+
 return new Descriptor(directory, keyspace, columnFamily, maxGen + 1, 
Descriptor.Type.TEMP).filenameFor(Component.DATA);
 }
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/84bc49e9/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java 
b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
index bf4da24..f302599 100644
--- a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
@@ -28,6 +28,7 @@ import java.util.List;
 import java.util.Map;
 
 import com.google.common.collect.ImmutableMap;
+import com.google.common.collect.Iterables;
 
 import org.apache.cassandra.cql3.statements.*;
 import org.apache.cassandra.cql3.*;
@@ -335,25 +336,31 @@ public class CQLSSTableWriter implements Closeable
 {
 try
 {
-this.schema = getStatement(schema, CreateTableStatement.class, 
CREATE TABLE).left.getCFMetaData().rebuild();
-
-// We need to register the keyspace/table metadata through 
Schema, otherwise we won't be able to properly
-// build the insert statement in using().
-if (Schema.instance.getKSMetaData(this.schema.ksName) == null)
-{
-KSMetaData ksm = KSMetaData.newKeyspace(this.schema.ksName,
-
AbstractReplicationStrategy.getClass(org.apache.cassandra.locator.SimpleStrategy),
-
ImmutableMap.of(replication_factor, 1),
-true,
-
Collections.singleton(this.schema));
-Schema.instance.load(ksm);
-

[jira] [Commented] (CASSANDRA-8209) Cassandra crashes when running on OpenJDK8 update 40

2014-10-30 Thread Jaroslav Kamenik (JIRA)


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

Jaroslav Kamenik commented on CASSANDRA-8209:
-

It is not JDK bug, it is new feature, they changed Class structure. So, you can 
wait until oracle release 8u40 and everyone who updates will have unusable 
Cassandra. Or fix it before release...

 Cassandra crashes when running on OpenJDK8 update 40
 

 Key: CASSANDRA-8209
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jaroslav Kamenik

 It seems that problem is change made in update 40 - 
 https://bugs.openjdk.java.net/browse/JDK-6642881
 result is:
 java.lang.SecurityException: Cannot make java.lang.Class.classLoader 
 accessible
 at 
 java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) 
 ~[na:1.8.0_40-ea]
 at 
 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) 
 ~[na:1.8.0_40-ea]
 at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) 
 ~[jamm-0.2.6.jar:na]
 at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) 
 ~[jamm-0.2.6.jar:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
 [na:1.8.0_40-ea]
 at 
 org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
 [apache-cassandra-2.1.1.jar:2.1.1]
 at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea]



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

[jira] [Commented] (CASSANDRA-8209) Cassandra crashes when running on OpenJDK8 update 40


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

Philip Thompson commented on CASSANDRA-8209:


[~mshuler] The linked openjdk ticket is a resolved enhancement.

 Cassandra crashes when running on OpenJDK8 update 40
 

 Key: CASSANDRA-8209
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jaroslav Kamenik

 It seems that problem is change made in update 40 - 
 https://bugs.openjdk.java.net/browse/JDK-6642881
 result is:
 java.lang.SecurityException: Cannot make java.lang.Class.classLoader 
 accessible
 at 
 java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) 
 ~[na:1.8.0_40-ea]
 at 
 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) 
 ~[na:1.8.0_40-ea]
 at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) 
 ~[jamm-0.2.6.jar:na]
 at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) 
 ~[jamm-0.2.6.jar:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
 [na:1.8.0_40-ea]
 at 
 org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
 [apache-cassandra-2.1.1.jar:2.1.1]
 at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea]



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

[jira] [Updated] (CASSANDRA-8171) Clean up generics


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

Joshua McKenzie updated CASSANDRA-8171:
---
Fix Version/s: 2.1.2

 Clean up generics
 -

 Key: CASSANDRA-8171
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8171
 Project: Cassandra
  Issue Type: Improvement
Reporter: Branimir Lambov
Assignee: Branimir Lambov
Priority: Minor
 Fix For: 2.1.2

 Attachments: 8171.patch


 Some uses of generics in the code are causing much more harm than good, and 
 in some cases generic types are used unsafely, hiding potential problems in 
 the code.
 Generics need to be cleaned up to clarify the types, remove unnecessary type 
 specialization when it does not make sense, and significantly reduce the 
 number of unhelpful warnings.



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

[jira] [Commented] (CASSANDRA-8171) Clean up generics


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

Joshua McKenzie commented on CASSANDRA-8171:


[~blambov]: could we get a version of this patch for the cassandra-2.1 branch?

 Clean up generics
 -

 Key: CASSANDRA-8171
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8171
 Project: Cassandra
  Issue Type: Improvement
Reporter: Branimir Lambov
Assignee: Branimir Lambov
Priority: Minor
 Fix For: 2.1.2

 Attachments: 8171.patch


 Some uses of generics in the code are causing much more harm than good, and 
 in some cases generic types are used unsafely, hiding potential problems in 
 the code.
 Generics need to be cleaned up to clarify the types, remove unnecessary type 
 specialization when it does not make sense, and significantly reduce the 
 number of unhelpful warnings.



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

[jira] [Issue Comment Deleted] (CASSANDRA-8147) Secondary indexing of map keys does not work properly when mixing contains and contains_key

2014-10-30 Thread Tyler Hobbs (JIRA)


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

Tyler Hobbs updated CASSANDRA-8147:
---
Comment: was deleted

(was: Git bisect shows that CASSANDRA-6782 is the cause for this.)

 Secondary indexing of map keys does not work properly when mixing contains 
 and contains_key
 ---

 Key: CASSANDRA-8147
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8147
 Project: Cassandra
  Issue Type: Bug
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
Priority: Minor
 Attachments: CASSANDRA-8147-V2.txt, CASSANDRA-8147.txt


 If you have a table with a map column and an index on the map key selecting 
 data using a contains key and a contains will not return the expected data.
 The problem can be reproduced using the following unit test:
 {code}
 @Test
 public void testMapKeyContainsAndValueContains() throws Throwable
 {
 createTable(CREATE TABLE %s (account text, id int, categories 
 maptext,text, PRIMARY KEY (account, id)));
 createIndex(CREATE INDEX ON %s(keys(categories)));
 execute(INSERT INTO %s (account, id , categories) VALUES (?, ?, ?), 
 test, 5, map(lmn, foo));
 assertRows(execute(SELECT * FROM %s WHERE account = ? AND id = ? AND 
 categories CONTAINS KEY ? AND categories CONTAINS ? ALLOW FILTERING, test, 
 5, lmn, foo), row(test, 5, map(lmn, foo)));  
 }
 {code}



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

[1/3] git commit: fix broken build - damnit, carl

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 84bc49e90 - 2e37655f9
  refs/heads/trunk fbb6b8abf - 8174dabf3


fix broken build - damnit, carl


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

Branch: refs/heads/cassandra-2.1
Commit: 2e37655f945e6ed464b65a190fd544970975d129
Parents: 84bc49e
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 30 11:09:38 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 30 11:09:38 2014 -0500

--
 .../unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e37655f/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java 
b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
index 6176505..61b8b83 100644
--- a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
+++ b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
@@ -248,7 +248,7 @@ public class CQLSSTableWriterTest
 
 loader.stream().get();
 
-UntypedResultSet rs = QueryProcessor.processInternal(SELECT * FROM 
cql_keyspace.table2;);
+UntypedResultSet rs = QueryProcessor.executeInternal(SELECT * FROM 
cql_keyspace.table2;);
 assertEquals(threads.length * NUMBER_WRITES_IN_RUNNABLE, rs.size());
 }
 }

[2/3] git commit: fix broken build - damnit, carl

fix broken build - damnit, carl


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

Branch: refs/heads/trunk
Commit: 2e37655f945e6ed464b65a190fd544970975d129
Parents: 84bc49e
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 30 11:09:38 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 30 11:09:38 2014 -0500

--
 .../unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e37655f/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java 
b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
index 6176505..61b8b83 100644
--- a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
+++ b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
@@ -248,7 +248,7 @@ public class CQLSSTableWriterTest
 
 loader.stream().get();
 
-UntypedResultSet rs = QueryProcessor.processInternal(SELECT * FROM 
cql_keyspace.table2;);
+UntypedResultSet rs = QueryProcessor.executeInternal(SELECT * FROM 
cql_keyspace.table2;);
 assertEquals(threads.length * NUMBER_WRITES_IN_RUNNABLE, rs.size());
 }
 }

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

Merge branch 'cassandra-2.1' into trunk


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

Branch: refs/heads/trunk
Commit: 8174dabf33e9e6cbdf2424692a9ee22df10f77f8
Parents: fbb6b8a 2e37655
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Oct 30 11:09:44 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Oct 30 11:09:44 2014 -0500

--
 .../unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8174dabf/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
--

[jira] [Commented] (CASSANDRA-7979) Acceptable time skew for C*

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

Joshua McKenzie commented on CASSANDRA-7979:

Ah - that's on me. I missed that we were storing the value back in
colUpdateTimeDelta - ignore that bit of feedback.

That kills 2 birds with one stone w/regards to my notes above. If you can
could clean up the spacing inconsistencies and comment the colUpdateTimeDelta
holding min value logic, a 2.0 branch and 2.1 branch patch ought to do it.

Acceptable time skew for C*
---

Key: CASSANDRA-7979
URL: https://issues.apache.org/jira/browse/CASSANDRA-7979
Project: Cassandra
Issue Type: Improvement
Reporter: sankalp kohli
Assignee: sankalp kohli
Priority: Minor
Attachments: 2.0_7979.diff, trunk_7979.diff

It is very hard to know the bounds on clock skew required for C* to work
properly. Since the resolution is based on time and is at thrift column
level, it depends on the application. How fast is the application updating
the same column. If you update a column say after 5 millisecond and the clock
skew is more than that, you might not see the updates in correct order.
In this JIRA, I am proposing a change which will answer this question: How
much clock skew is acceptable for a given application. This will help answer
the question whether the system needs some alternate NTP algorithms to keep
time in sync.
If we measure the time difference between two updates to the same column, we
will be able to answer the question on clock skew.
We can implement this in memtable(AtomicSortedColumns.addColumn). If we find
that a column is updated within say 100 millisecond, add the diff to a
histogram. Since this might have performance issues, we might want to have
some throttling like randomization or only enable it for a small time via
nodetool.
With this histogram, we will know what is an acceptable clock skew.
Also apart from column resolution, is there any other area which will be
affected by clock skew?
Note: For the sake of argument, I am not talking about back date deletes or
application modified timestamps.

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

[jira] [Reopened] (CASSANDRA-8209) Cassandra crashes when running on OpenJDK8 update 40


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

Michael Shuler reopened CASSANDRA-8209:
---
  Assignee: T Jake Luciani

 Cassandra crashes when running on OpenJDK8 update 40
 

 Key: CASSANDRA-8209
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jaroslav Kamenik
Assignee: T Jake Luciani

 It seems that problem is change made in update 40 - 
 https://bugs.openjdk.java.net/browse/JDK-6642881
 result is:
 java.lang.SecurityException: Cannot make java.lang.Class.classLoader 
 accessible
 at 
 java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) 
 ~[na:1.8.0_40-ea]
 at 
 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) 
 ~[na:1.8.0_40-ea]
 at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) 
 ~[jamm-0.2.6.jar:na]
 at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) 
 ~[jamm-0.2.6.jar:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
 [na:1.8.0_40-ea]
 at 
 org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
 [apache-cassandra-2.1.1.jar:2.1.1]
 at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea]



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

[jira] [Commented] (CASSANDRA-8168) Require Java 8


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

Michael Shuler commented on CASSANDRA-8168:
---

And an issue with a new feature in the current dev build of OpenJDK8: 
https://bugs.openjdk.java.net/browse/JDK-6642881 reported in CASSANDRA-8209 

 Require Java 8
 --

 Key: CASSANDRA-8168
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8168
 Project: Cassandra
  Issue Type: Task
Reporter: T Jake Luciani
Assignee: T Jake Luciani
 Fix For: 3.0


 This is to discuss requiring Java 8 for version = 3.0  
 There are a couple big reasons for this.
 * Better support for complex async work  e.g (CASSANDRA-5239)
 http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html
 * Use Nashorn for Javascript UDFs CASSANDRA-7395



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

[jira] [Commented] (CASSANDRA-8208) Inconsistent failure handling with repair

2014-10-30 Thread Yuki Morishita (JIRA)


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

Yuki Morishita commented on CASSANDRA-8208:
---

I think you are right. Maybe we can just switch from Futures.allAsList() (its 
returned Future immediately fails when one of given Futures fails) to 
Futures.successfulAsList() and check null for failed repair in callback.

 Inconsistent failure handling with repair
 -

 Key: CASSANDRA-8208
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8208
 Project: Cassandra
  Issue Type: Bug
Reporter: Marcus Eriksson
 Fix For: 3.0


 I think we introduced this with CASSANDRA-6455, problem is that we now treat 
 all repair futures as a single unit (Futures.allAsList(..)) which makes the 
 whole thing fail if one sub-future fails. Also, when one of those fail, we 
 notify nodetool that we failed and we stop the executor with shutdownNow() 
 which throws out any pending RepairJobs.
 [~yukim] I think we used to be able to proceed with the other RepairSessions 
 even if one fails, right? If not, we should probably call cancel on the 
 RepairJob runnables which are in queue for the executor after calling 
 shutdownNow() in repairComplete() in StorageService. 



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

[jira] [Created] (CASSANDRA-8223) Make comments/default paths in cassandra-env.ps1 more Windows-centric

Joshua McKenzie created CASSANDRA-8223:
--

 Summary: Make comments/default paths in cassandra-env.ps1 more 
Windows-centric
 Key: CASSANDRA-8223
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8223
 Project: Cassandra
  Issue Type: Improvement
Reporter: Joshua McKenzie
Assignee: Joshua McKenzie
Priority: Trivial
 Fix For: 2.1.2


When porting launch-script functionality over some of the disabled-by-default 
options in cassandra-env.ps1 weren't modified.  They're decidedly non-Windows:
{code}
   # Configure the following for JEMallocAllocator and if jemalloc is not 
available in the system
# library path (Example: /usr/local/lib/). Usually make install will do 
the right thing.
{code}

Trivial effort - just update those to reflect sane windows 
defaults/paths/ecosystem.  Should have 0 effect on runtime defaults as they're 
all already Windows-ified.



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

svn commit: r1635564 - in /cassandra/site: publish/index.html publish/media/img/summit14uk.png publish/media/js/cassandra.js publish/media/js/jquery.curvycorners.min.js src/content/index.html src/medi

2014-10-30 Thread jbellis

Author: jbellis
Date: Thu Oct 30 17:55:37 2014
New Revision: 1635564

URL: http://svn.apache.org/r1635564
Log:
add London Summit banner

Added:
cassandra/site/publish/media/img/summit14uk.png   (with props)
cassandra/site/src/media/img/summit14uk.png   (with props)
Modified:
cassandra/site/publish/index.html
cassandra/site/publish/media/js/cassandra.js
cassandra/site/publish/media/js/jquery.curvycorners.min.js
cassandra/site/src/content/index.html

Modified: cassandra/site/publish/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/index.html?rev=1635564r1=1635563r2=1635564view=diff
==
--- cassandra/site/publish/index.html (original)
+++ cassandra/site/publish/index.html Thu Oct 30 17:55:37 2014
@@ -86,8 +86,8 @@
 
 
 div class=span-24
-a 
href=http://www.cvent.com/events/cassandra-summit-2014/event-summary-176f061a4b144525ae05f18cd9a9cb12.aspx;
-  img src=/media/img/summit14.jpg
+a 
href=http://www.cvent.com/events/cassandra-summit-europe-2014/event-summary-71db455406e34b089d00b5f99f77eb74.aspx;
+  img src=/media/img/summit14uk.png
 /a
 /div
 

Added: cassandra/site/publish/media/img/summit14uk.png
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/media/img/summit14uk.png?rev=1635564view=auto
==
Binary file - no diff available.

Propchange: cassandra/site/publish/media/img/summit14uk.png
--
svn:mime-type = application/octet-stream

Modified: cassandra/site/publish/media/js/cassandra.js
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/media/js/cassandra.js?rev=1635564r1=1635563r2=1635564view=diff
==
--- cassandra/site/publish/media/js/cassandra.js (original)
+++ cassandra/site/publish/media/js/cassandra.js Thu Oct 30 17:55:37 2014
@@ -1 +1,5 @@
-$(document).ready(function(){$(.rc).corner();$(#tabs).tabs()});
\ No newline at end of file
+
+$(document).ready(function(){
+$('.rc').corner();
+$(#tabs).tabs();
+});

Modified: cassandra/site/publish/media/js/jquery.curvycorners.min.js
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/media/js/jquery.curvycorners.min.js?rev=1635564r1=1635563r2=1635564view=diff
==
--- cassandra/site/publish/media/js/jquery.curvycorners.min.js (original)
+++ cassandra/site/publish/media/js/jquery.curvycorners.min.js Thu Oct 30 
17:55:37 2014
@@ -1 +1,38 @@
-(function(a){a.fn.corner=function(n){function i(A,x,u){var 
r=parseInt(A.substr(1,2),16);var y=parseInt(A.substr(3,2),16);var 
t=parseInt(A.substr(5,2),16);var q=parseInt(x.substr(1,2),16);var 
w=parseInt(x.substr(3,2),16);var 
s=parseInt(x.substr(5,2),16);if(u1||u0){u=1}var 
v=Math.round((r*u)+(q*(1-u)));if(v255){v=255}if(v0){v=0}var 
p=Math.round((y*u)+(w*(1-u)));if(p255){p=255}if(p0){p=0}var 
o=Math.round((t*u)+(s*(1-u)));if(o255){o=255}if(o0){o=0}return#+e(v)+e(p)+e(o)}function
 e(o){base=o/16;rem=o%16;base=base-(rem/16);baseS=f(base);remS=f(rem);return 
baseS++remS}function f(o){if((o=0)(o=9)){return o}else{switch(o){case 
10:returnA;case 11:returnB;case 12:returnC;case 13:returnD;case 
14:returnE;case 15:returnF}returnF}}function l(w,v,o){var q=0;var p=new 
Array(1);var u=new Array(1);var A=0;var s=;var 
t=Math.sqrt((Math.pow(o,2)-Math.pow(w,2)));if((t=v)(t(v+1))){s=Left;p[A]=0;u[A]=t-v;A=A+1}var
 t=Math.sqrt((Math.pow(o,2)-Math.pow(v+1,2)));if((t=w)
 (t(w+1))){s=s+Top;p[A]=t-w;u[A]=1;A=A+1}var 
t=Math.sqrt((Math.pow(o,2)-Math.pow(w+1,2)));if((t=v)(t(v+1))){s=s+Right;p[A]=1;u[A]=t-v;A=A+1}var
 
t=Math.sqrt((Math.pow(o,2)-Math.pow(v,2)));if((t=w)(t(w+1))){s=s+Bottom;p[A]=t-w;u[A]=0}switch(s){caseLeftRight:q=Math.min(u[0],u[1])+((Math.max(u[0],u[1])-Math.min(u[0],u[1]))/2);break;caseTopRight:q=1-(((1-p[0])*(1-u[1]))/2);break;caseTopBottom:q=Math.min(p[0],p[1])+((Math.max(p[0],p[1])-Math.min(p[0],p[1]))/2);break;caseLeftBottom:q=(u[0]*p[1])/2;break;default:q=1}return
 q}function c(p){try{var q=j(p);var u=parseInt(q[0]);var s=parseInt(q[1]);var 
o=parseInt(q[2]);var r=#+e(u)+e(s)+e(o)}catch(t){alert(There was an error 
converting the RGB value to Hexadecimal in function rgb2Hex)}return r}function 
j(o){var q=o.substring(4,o.indexOf()));var p=q.split(, );return p}function 
b(p){var 
o=transparent;if(p!=p!=transparent){if(p.substr(0,3)==rgbp.substr(0,4)!=rgba){o=c(p)}else{if(p.length==4){o=#+p.subs
 
tring(1,2)+p.substring(1,2)+p.substring(2,3)+p.substring(2,3)+p.substring(3,4)+p.substring(3,4)}else{o=p}}}return
 o}function h(o){return 
parseInt(((o!=autoo.indexOf(%)==-1o!=o.indexOf(px)!==-1)?o.slice(0,o.indexOf(px)):0))}function
 m(v,F,B,p,x,C,E,s,y,w,D,o,u,r){var A=a(v);var

[jira] [Updated] (CASSANDRA-7983) nodetool repair triggers OOM

2014-10-30 Thread Jose Martinez Poblete (JIRA)


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

Jose Martinez Poblete updated CASSANDRA-7983:
-
Description: 
Customer has a 3 node cluster with 500Mb data on each node

{noformat}
[cassandra@nbcqa-chc-a02 ~]$ nodetool status
Note: Ownership information does not include topology; for complete 
information, specify a keyspace
Datacenter: CH2
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  AddressLoad   Tokens  Owns   Host ID
   Rack
UN  162.150.4.234  255.26 MB  256 33.2%  
4ad1b6a8-8759-4920-b54a-f059126900df  RAC1
UN  162.150.4.235  318.37 MB  256 32.6%  
3eb0ec58-4b81-442e-bee5-4c91da447f38  RAC1
UN  162.150.4.167  243.7 MB   256 34.2%  
5b2c1900-bf03-41c1-bb4e-82df1655b8d8  RAC1
[cassandra@nbcqa-chc-a02 ~]$
{noformat}

After we run repair command, system runs into OOM after some 45 minutes
Nothing else is running

{noformat}
[cassandra@nbcqa-chc-a02 ~]$ date
Fri Sep 19 15:55:33 UTC 2014
[cassandra@nbcqa-chc-a02 ~]$ nodetool repair -st -9220354588320251877 -et 
-9220354588320251873
Sep 19, 2014 4:06:08 PM ClientCommunicatorAdmin Checker-run
WARNING: Failed to check the connection: java.net.SocketTimeoutException: Read 
timed out
{noformat}

Here is when we run OOM

{noformat}
ERROR [ReadStage:28914] 2014-09-19 16:34:50,381 CassandraDaemon.java (line 199) 
Exception in thread Thread[ReadStage:28914,5,main]
java.lang.OutOfMemoryError: Java heap space
at 
org.apache.cassandra.io.util.RandomAccessReader.init(RandomAccessReader.java:69)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.init(CompressedRandomAccessReader.java:76)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:43)
at 
org.apache.cassandra.io.util.CompressedPoolingSegmentedFile.createReader(CompressedPoolingSegmentedFile.java:48)
at 
org.apache.cassandra.io.util.PoolingSegmentedFile.getSegment(PoolingSegmentedFile.java:39)
at 
org.apache.cassandra.io.sstable.SSTableReader.getFileDataInput(SSTableReader.java:1195)
at 
org.apache.cassandra.db.columniterator.SimpleSliceReader.init(SimpleSliceReader.java:57)
at 
org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:65)
at 
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:42)
at 
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:167)
at 
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:62)
at 
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:250)
at 
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53)
at 
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1547)
at 
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1376)
at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:333)
at 
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:65)
at 
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1363)
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1927)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{noformat}

Cassandra process pegs 1 of the 8 CPU's 100% 

{noformat}
top - 16:50:07 up 11 days,  2:01,  2 users,  load average: 0.54, 0.60, 0.65
Tasks: 175 total,   1 running, 174 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.7%us,  0.3%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.3%us,  0.3%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.3%us,  0.3%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.3%st
Cpu6  :  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.3%us,  0.3%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  16332056k total, 16167212k used,   164844k free,   149956k buffers
Swap:0k total,0k used,0k free,  8360056k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 2161 cassandr  20   0 11.5g 6.9g 227m S 107.8 44.0 281:59.49 java
 9942 root  20   0  106m 2320 1344 S  1.0  0.0   0:00.03 dhclient-script
28969 opscente  20   0 4479m 188m

[jira] [Updated] (CASSANDRA-8179) No error message shown when starting Cassandra on Windows if Cassandra is already running


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

Joshua McKenzie updated CASSANDRA-8179:
---
Attachment: 8179_v1.txt

v1 attached.  cassandra.ps1 parses out the data in cassandra.yaml and JMX_PORT 
from cassandra-env.ps1, and then does async connect to each port based on 
listed listen_address/rpc_address + port as appropriate.  If any of them 
connect, prints out which was already open and errors out.

It's a little more heavy-handed than parsing netstat output but should be 
fairly robust and adds about 125ms to startup time (25ms async timeout on each 
port).  Confirmed that develop branch on ccm starts successfully with this 
change w/3 nodes, and used nc to bind to various ports and confirm it seems to 
work locally.

 No error message shown when starting Cassandra on Windows if Cassandra is 
 already running
 -

 Key: CASSANDRA-8179
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8179
 Project: Cassandra
  Issue Type: Bug
 Environment: Windows 7
Reporter: Philip Thompson
Assignee: Joshua McKenzie
Priority: Minor
  Labels: windows
 Fix For: 2.1.2

 Attachments: 8179_v1.txt


 The output from running cassandra.bat while Cassandra is already running 
 gives no indication that Cassandra was already running, or that the command 
 failed. Instead it prints out {code}Starting Cassandra Server.{code}



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

[jira] [Commented] (CASSANDRA-7979) Acceptable time skew for C*

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

sankalp kohli commented on CASSANDRA-7979:
--

Added 3 patches for 2.0,2.1 and trunk.

Acceptable time skew for C*
---

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

[jira] [Updated] (CASSANDRA-7979) Acceptable time skew for C*

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

sankalp kohli updated CASSANDRA-7979:
-
Attachment: trunk_7979_v2.txt
2.0_7979_v2.txt
2.1_7979_v2.txt

Acceptable time skew for C*
---

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

[jira] [Updated] (CASSANDRA-8179) No error message shown when starting Cassandra on Windows if Cassandra is already running


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

Joshua McKenzie updated CASSANDRA-8179:
---
Reviewer: Philip Thompson

 No error message shown when starting Cassandra on Windows if Cassandra is 
 already running
 -

 Key: CASSANDRA-8179
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8179
 Project: Cassandra
  Issue Type: Bug
 Environment: Windows 7
Reporter: Philip Thompson
Assignee: Joshua McKenzie
Priority: Minor
  Labels: windows
 Fix For: 2.1.2

 Attachments: 8179_v1.txt


 The output from running cassandra.bat while Cassandra is already running 
 gives no indication that Cassandra was already running, or that the command 
 failed. Instead it prints out {code}Starting Cassandra Server.{code}



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

[jira] [Commented] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)


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

Robert Stupp commented on CASSANDRA-7438:
-

Did a walkthrough to lruc 0.7, too...

Altogether +1 on the current state :)

Just one NIT:
* Move {{Preconditions.checkArgument(capacity  0 ...}} in {{LRUCache.java}} 
from {{capacity()}} to {{setCapacity}}

One thing regarding saved row caches: We should ensure that changes in the 
serialized format of saved row caches are detected (and either converted during 
load or just discarded)

Comments would be nice to have in a future version.

* Think you need to add the APLv2 license header to all source files ;)
* The NEWS, COPYING and AUTHORS files in {{lruc/src/native}} and {{lurk}} are 
blank
* {{stats}} struct is heavily used using CAS - maybe think of aligning the 
individual values to separate CPU cache lines to reduce CPU cache refreshes
* similar for {{item.refcount}} - it refcount is updated, the whole cache line 
needs to be re-fetched (CPU)
* {{o.a.c.cache.ICacheProvider.RowKeySerializer}} tries to „compress“ the two 
{{long}} values of UUID via 
{{EncodedDataOutputStream}}/{{EncodedDataInputStream}} - this is usually not 
possible for long values of a UUID resulting in bigger serialized 
representations than necessary (this is what the default serialization e.g. 
UUIDSerializer does)


 Serializing Row cache alternative (Fully off heap)
 --

 Key: CASSANDRA-7438
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7438
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: Linux
Reporter: Vijay
Assignee: Vijay
  Labels: performance
 Fix For: 3.0

 Attachments: 0001-CASSANDRA-7438.patch


 Currently SerializingCache is partially off heap, keys are still stored in 
 JVM heap as BB, 
 * There is a higher GC costs for a reasonably big cache.
 * Some users have used the row cache efficiently in production for better 
 results, but this requires careful tunning.
 * Overhead in Memory for the cache entries are relatively high.
 So the proposal for this ticket is to move the LRU cache logic completely off 
 heap and use JNI to interact with cache. We might want to ensure that the new 
 implementation match the existing API's (ICache), and the implementation 
 needs to have safe memory access, low overhead in memory and less memcpy's 
 (As much as possible).
 We might also want to make this cache configurable.



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

[jira] [Commented] (CASSANDRA-8209) Cassandra crashes when running on OpenJDK8 update 40


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

Robert Stupp commented on CASSANDRA-8209:
-

Hm - if the memory-meter starts to count instances of {{java.lang.Class}}, then 
there seems to be another issue with 
{{SelectStatement#measureForPreparedCache}} that counts objects not related to 
the current statement. Guess it's something in {{SelectStatement#selection}} - 
maybe something completely not related to a prepared statement. Or am I wrong?

 Cassandra crashes when running on OpenJDK8 update 40
 

 Key: CASSANDRA-8209
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jaroslav Kamenik
Assignee: T Jake Luciani

 It seems that problem is change made in update 40 - 
 https://bugs.openjdk.java.net/browse/JDK-6642881
 result is:
 java.lang.SecurityException: Cannot make java.lang.Class.classLoader 
 accessible
 at 
 java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) 
 ~[na:1.8.0_40-ea]
 at 
 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) 
 ~[na:1.8.0_40-ea]
 at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) 
 ~[jamm-0.2.6.jar:na]
 at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) 
 ~[jamm-0.2.6.jar:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
 [na:1.8.0_40-ea]
 at 
 org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
 [apache-cassandra-2.1.1.jar:2.1.1]
 at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea]



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

[jira] [Created] (CASSANDRA-8224) Checksum Gossip state

sankalp kohli created CASSANDRA-8224:


 Summary: Checksum Gossip state
 Key: CASSANDRA-8224
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8224
 Project: Cassandra
  Issue Type: Improvement
Reporter: sankalp kohli
Priority: Minor


 We have seen that a single machine with bad memory can corrupt the gossip of 
other nodes and cause entire cluster to be affected. If we store and pass the 
checksum of the entire state, we can detect corruption. If a bad machine tries 
to bump the generation number or other things, it will be detected and ignored.



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

[jira] [Assigned] (CASSANDRA-8224) Checksum Gossip state


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

sankalp kohli reassigned CASSANDRA-8224:


Assignee: sankalp kohli

 Checksum Gossip state
 -

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

  We have seen that a single machine with bad memory can corrupt the gossip of 
 other nodes and cause entire cluster to be affected. If we store and pass the 
 checksum of the entire state, we can detect corruption. If a bad machine 
 tries to bump the generation number or other things, it will be detected and 
 ignored.



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

[jira] [Commented] (CASSANDRA-8224) Checksum Gossip state


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

sankalp kohli commented on CASSANDRA-8224:
--

cc [~brandon.williams]

 Checksum Gossip state
 -

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

  We have seen that a single machine with bad memory can corrupt the gossip of 
 other nodes and cause entire cluster to be affected. If we store and pass the 
 checksum of the entire state, we can detect corruption. If a bad machine 
 tries to bump the generation number or other things, it will be detected and 
 ignored.



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

[jira] [Commented] (CASSANDRA-8136) Windows Service never finishes shutting down


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

Philip Thompson commented on CASSANDRA-8136:


+1. Starting and stopping via services.msc works great, doesn't affect normal 
start/stop.

 Windows Service never finishes shutting down
 

 Key: CASSANDRA-8136
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8136
 Project: Cassandra
  Issue Type: Bug
Reporter: Joshua McKenzie
Assignee: Joshua McKenzie
Priority: Minor
  Labels: windows
 Fix For: 2.1.2

 Attachments: 8136_v1.txt


 When using procrun and the -install combination on Windows and starting 
 cassandra via services.msc, stopping the service never completes and gets 
 stuck in stopping status forever.  Probably related to:
 {code}
 public void stop()
 {
 // this doesn't entirely shut down Cassandra, just the RPC server.
 // jsvc takes care of taking the rest down
 logger.info(Cassandra shutting down...);
 thriftServer.stop();
 nativeServer.stop();
 }
 {code}
 procrun calls the StopMethod as CassandraDaemon.stop so we may need to either 
 a) augment what procrun's doing or b) add a more comprehensive stop to be 
 called on Windows shutdown.



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

[jira] [Updated] (CASSANDRA-8028) Unable to compute when histogram overflowed

2014-10-30 Thread Carl Yeksigian (JIRA)


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

Carl Yeksigian updated CASSANDRA-8028:
--
Attachment: sstable-histogrambuster.tar.bz2
8028-2.1-clean.txt

I've attached a rebased patch, and the sstable that I used to make sure that 
the overflow was fixed.

The schema is:
{noformat}
CREATE TABLE sstable.histogrambuster (name text, id bigint, PRIMARY KEY (name, 
id))
{noformat}


 Unable to compute when histogram overflowed
 ---

 Key: CASSANDRA-8028
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8028
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: Linux
Reporter: Gianluca Borello
Assignee: Carl Yeksigian
 Fix For: 2.1.2

 Attachments: 8028-2.1-clean.txt, 8028-2.1.txt, 8028-trunk.txt, 
 sstable-histogrambuster.tar.bz2


 It seems like with 2.1.0 histograms can't be computed most of the times:
 $ nodetool cfhistograms draios top_files_by_agent1
 nodetool: Unable to compute when histogram overflowed
 See 'nodetool help' or 'nodetool help command'.
 I can probably find a way to attach a .cql script to reproduce it, but I 
 suspect it must be obvious to replicate it as it happens on more than 50% of 
 my column families.



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

[jira] [Commented] (CASSANDRA-8160) CF level option to call posix_fadvise for sstables on creation and startup

2014-10-30 Thread Matt Stump (JIRA)

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

Matt Stump commented on CASSANDRA-8160:
---

I have something semi-functional against trunk, but it's going to be another
week or two before I can touch it again. I realized afterwards what I should
really be targeting is 2.1 and 2.0 because 3.0 is going to blow up all this
code.

The constructor logic for sstable reader is a bit of a mess, so it's difficult
to find a clean entry point to do this that doesn't include lots of code
duplication, and yet distinguish between opening an sstable on boot vs an
sstable after write.

That being said I was at a retailer, and the newly written sstables weren't
being moved up into the buffer cache as aggressively as one would hope. After
reading the sstables out to /dev/null, forcing the population of the buffer
cache, the percentage of queries over SLA went from 15% down to 1%, for a node
that had a dataset of 5GB and 256GB of memory.

CF level option to call posix_fadvise for sstables on creation and startup
--

Key: CASSANDRA-8160
URL: https://issues.apache.org/jira/browse/CASSANDRA-8160
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Matt Stump
Assignee: Branimir Lambov
Priority: Minor
Fix For: 2.1.2

We should have a CF level configuration with will result in posix_fadvise
being called for sstables for that CF. It should be called on node startup
and for new sstables. This should be configurable per CF to allow for some
CFs to be prioritized above others. Not sure if we should use
POSIX_FADV_SEQUENTIAL or POSIX_FADV_WILLNEED.

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

[jira] [Commented] (CASSANDRA-8179) No error message shown when starting Cassandra on Windows if Cassandra is already running


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

Philip Thompson commented on CASSANDRA-8179:


+1, port checking method looks reasonable. Start/stop behaves correctly.

 No error message shown when starting Cassandra on Windows if Cassandra is 
 already running
 -

 Key: CASSANDRA-8179
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8179
 Project: Cassandra
  Issue Type: Bug
 Environment: Windows 7
Reporter: Philip Thompson
Assignee: Joshua McKenzie
Priority: Minor
  Labels: windows
 Fix For: 2.1.2

 Attachments: 8179_v1.txt


 The output from running cassandra.bat while Cassandra is already running 
 gives no indication that Cassandra was already running, or that the command 
 failed. Instead it prints out {code}Starting Cassandra Server.{code}



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

[jira] [Commented] (CASSANDRA-8209) Cassandra crashes when running on OpenJDK8 update 40


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

Robert Stupp commented on CASSANDRA-8209:
-

Bug is reproducible with 
{{PreparedStatementsTest#testStatementRePreparationOnReconnect}} using 
1.8.0_40-ea-b12 - attached patch is for jamm

 Cassandra crashes when running on OpenJDK8 update 40
 

 Key: CASSANDRA-8209
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jaroslav Kamenik
Assignee: T Jake Luciani
 Attachments: 8209.txt


 It seems that problem is change made in update 40 - 
 https://bugs.openjdk.java.net/browse/JDK-6642881
 result is:
 java.lang.SecurityException: Cannot make java.lang.Class.classLoader 
 accessible
 at 
 java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) 
 ~[na:1.8.0_40-ea]
 at 
 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) 
 ~[na:1.8.0_40-ea]
 at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) 
 ~[jamm-0.2.6.jar:na]
 at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) 
 ~[jamm-0.2.6.jar:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
 [na:1.8.0_40-ea]
 at 
 org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
 [apache-cassandra-2.1.1.jar:2.1.1]
 at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea]



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

[jira] [Updated] (CASSANDRA-8209) Cassandra crashes when running on OpenJDK8 update 40


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

Robert Stupp updated CASSANDRA-8209:

Attachment: 8209.txt

 Cassandra crashes when running on OpenJDK8 update 40
 

 Key: CASSANDRA-8209
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jaroslav Kamenik
Assignee: T Jake Luciani
 Attachments: 8209.txt


 It seems that problem is change made in update 40 - 
 https://bugs.openjdk.java.net/browse/JDK-6642881
 result is:
 java.lang.SecurityException: Cannot make java.lang.Class.classLoader 
 accessible
 at 
 java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) 
 ~[na:1.8.0_40-ea]
 at 
 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) 
 ~[na:1.8.0_40-ea]
 at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) 
 ~[jamm-0.2.6.jar:na]
 at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) 
 ~[jamm-0.2.6.jar:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
 [na:1.8.0_40-ea]
 at 
 org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
 [apache-cassandra-2.1.1.jar:2.1.1]
 at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea]



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

[jira] [Commented] (CASSANDRA-8209) Cassandra crashes when running on OpenJDK8 update 40


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

Robert Stupp commented on CASSANDRA-8209:
-

Side note: the line numbers reported by jamm-0.2.6.jar in C* lib/ do not match 
the line numbers from the 0.2.6 source on github :(

 Cassandra crashes when running on OpenJDK8 update 40
 

 Key: CASSANDRA-8209
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jaroslav Kamenik
Assignee: T Jake Luciani
 Attachments: 8209.txt


 It seems that problem is change made in update 40 - 
 https://bugs.openjdk.java.net/browse/JDK-6642881
 result is:
 java.lang.SecurityException: Cannot make java.lang.Class.classLoader 
 accessible
 at 
 java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) 
 ~[na:1.8.0_40-ea]
 at 
 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) 
 ~[na:1.8.0_40-ea]
 at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) 
 ~[jamm-0.2.6.jar:na]
 at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) 
 ~[jamm-0.2.6.jar:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
 [na:1.8.0_40-ea]
 at 
 org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
 [apache-cassandra-2.1.1.jar:2.1.1]
 at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea]



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

[jira] [Commented] (CASSANDRA-8209) Cassandra crashes when running on OpenJDK8 update 40


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

Robert Stupp commented on CASSANDRA-8209:
-

bq. completely not related to a prepared statement. Or am I wrong?
I am wrong - {{Class}} was taken from {{j.u.EnumSet#elementType}}

 Cassandra crashes when running on OpenJDK8 update 40
 

 Key: CASSANDRA-8209
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jaroslav Kamenik
Assignee: T Jake Luciani
 Attachments: 8209.txt


 It seems that problem is change made in update 40 - 
 https://bugs.openjdk.java.net/browse/JDK-6642881
 result is:
 java.lang.SecurityException: Cannot make java.lang.Class.classLoader 
 accessible
 at 
 java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) 
 ~[na:1.8.0_40-ea]
 at 
 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) 
 ~[na:1.8.0_40-ea]
 at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) 
 ~[jamm-0.2.6.jar:na]
 at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) 
 ~[jamm-0.2.6.jar:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) 
 ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77)
  ~[apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at 
 io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
  [netty-all-4.0.23.Final.jar:4.0.23.Final]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
 [na:1.8.0_40-ea]
 at 
 org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
  [apache-cassandra-2.1.1.jar:2.1.1]
 at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
 [apache-cassandra-2.1.1.jar:2.1.1]
 at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea]



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

[jira] [Commented] (CASSANDRA-8004) Run LCS for both repaired and unrepaired data


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

Aleksey Yeschenko commented on CASSANDRA-8004:
--

Still looking at it. Other than a failing CrcCheckChanceTest, things mostly 
look good - or rather as good as we can make them in 2.1, without major 
internal changes (hopefully we'll be able to redesign the APIs surrounding 
compaction in 3.x).

Need a bit more time to make sure it doesn't break anything else though (incl. 
3rd party compaction strategies, in unexpected ways).

 Run LCS for both repaired and unrepaired data
 -

 Key: CASSANDRA-8004
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8004
 Project: Cassandra
  Issue Type: Bug
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
  Labels: compaction
 Fix For: 2.1.2


 If a user has leveled compaction configured, we should run that for both the 
 unrepaired and the repaired data. I think this would make things a lot easier 
 for end users
 It would simplify migration to incremental repairs as well, if a user runs 
 incremental repair on its nice leveled unrepaired data, we wont need to drop 
 it all to L0, instead we can just start moving sstables from the unrepaired 
 leveling straight into the repaired leveling
 Idea could be to have two instances of LeveledCompactionStrategy and move 
 sstables between the instances after an incremental repair run (and let LCS 
 be totally oblivious to whether it handles repaired or unrepaired data). Same 
 should probably apply to any compaction strategy, run two instances and 
 remove all repaired/unrepaired logic from the strategy itself.



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

[jira] [Created] (CASSANDRA-8225) Production-capable COPY FROM

2014-10-30 Thread Jonathan Ellis (JIRA)

Jonathan Ellis created CASSANDRA-8225:
-

 Summary: Production-capable COPY FROM
 Key: CASSANDRA-8225
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8225
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Reporter: Jonathan Ellis
 Fix For: 2.1.2


Via [~schumacr],

bq. I pulled down a sourceforge data generator and created a moc file of 
500,000 rows that had an incrementing sequence number, date, and SSN. I then 
used our COPY command and MySQL's LOAD DATA INFILE to load the file on my Mac. 
Results were: 

{noformat}
mysql load data infile '/Users/robin/dev/datagen3.txt'  into table p_test  
fields terminated by ',';
Query OK, 50 rows affected (2.18 sec)
{noformat}

C* 2.1.0 (pre-CASSANDRA-7405)
{noformat}
cqlsh:dev copy p_test from '/Users/robin/dev/datagen3.txt' with delimiter=',';
50 rows imported in 16 minutes and 45.485 seconds.
{noformat}

Cassandra 2.1.1:
{noformat}
cqlsh:dev copy p_test from '/Users/robin/dev/datagen3.txt' with delimiter=',';
Processed 50 rows; Write: 4037.46 rows/s
50 rows imported in 2 minutes and 3.058 seconds.
{noformat}

[jbellis] 7405 gets us almost an order of magnitude improvement.  Unfortunately 
we're still almost 2 orders slower than mysql.

I don't think we can continue to tell people, use sstableloader instead.  The 
number of users sophisticated enough to use the sstable writers is small and 
(relatively) decreasing as our user base expands.



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

[jira] [Commented] (CASSANDRA-8225) Production-capable COPY FROM

2014-10-30 Thread Jonathan Ellis (JIRA)


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

Jonathan Ellis commented on CASSANDRA-8225:
---

IMO we should

# Continue to use COPY FROM as the public face of this (no sense in having a 
slow and a fast way to do the same thing) but
# Call out to a Java utility that writes sstables and loads them
# Ultimately, we really want to just write the converted data out to the 
network directly; creating intermediate sstables is unnecessary.  But this can 
be a separate ticket. 

 Production-capable COPY FROM
 

 Key: CASSANDRA-8225
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8225
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Reporter: Jonathan Ellis
 Fix For: 2.1.2


 Via [~schumacr],
 bq. I pulled down a sourceforge data generator and created a moc file of 
 500,000 rows that had an incrementing sequence number, date, and SSN. I then 
 used our COPY command and MySQL's LOAD DATA INFILE to load the file on my 
 Mac. Results were: 
 {noformat}
 mysql load data infile '/Users/robin/dev/datagen3.txt'  into table p_test  
 fields terminated by ',';
 Query OK, 50 rows affected (2.18 sec)
 {noformat}
 C* 2.1.0 (pre-CASSANDRA-7405)
 {noformat}
 cqlsh:dev copy p_test from '/Users/robin/dev/datagen3.txt' with 
 delimiter=',';
 50 rows imported in 16 minutes and 45.485 seconds.
 {noformat}
 Cassandra 2.1.1:
 {noformat}
 cqlsh:dev copy p_test from '/Users/robin/dev/datagen3.txt' with 
 delimiter=',';
 Processed 50 rows; Write: 4037.46 rows/s
 50 rows imported in 2 minutes and 3.058 seconds.
 {noformat}
 [jbellis] 7405 gets us almost an order of magnitude improvement.  
 Unfortunately we're still almost 2 orders slower than mysql.
 I don't think we can continue to tell people, use sstableloader instead.  
 The number of users sophisticated enough to use the sstable writers is small 
 and (relatively) decreasing as our user base expands.



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

[jira] [Commented] (CASSANDRA-8225) Production-capable COPY FROM

2014-10-30 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna commented on CASSANDRA-8225:
-

We can also optimize the hadoop/spark method of bulk loading to write the 
converted data out to the network directly as well as part of this effort and 
just reuse the code.  Currently it uses a local directory to write it out 
first.  (spark bulk output is in progress)

 Production-capable COPY FROM
 

 Key: CASSANDRA-8225
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8225
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Reporter: Jonathan Ellis
 Fix For: 2.1.2


 Via [~schumacr],
 bq. I pulled down a sourceforge data generator and created a moc file of 
 500,000 rows that had an incrementing sequence number, date, and SSN. I then 
 used our COPY command and MySQL's LOAD DATA INFILE to load the file on my 
 Mac. Results were: 
 {noformat}
 mysql load data infile '/Users/robin/dev/datagen3.txt'  into table p_test  
 fields terminated by ',';
 Query OK, 50 rows affected (2.18 sec)
 {noformat}
 C* 2.1.0 (pre-CASSANDRA-7405)
 {noformat}
 cqlsh:dev copy p_test from '/Users/robin/dev/datagen3.txt' with 
 delimiter=',';
 50 rows imported in 16 minutes and 45.485 seconds.
 {noformat}
 Cassandra 2.1.1:
 {noformat}
 cqlsh:dev copy p_test from '/Users/robin/dev/datagen3.txt' with 
 delimiter=',';
 Processed 50 rows; Write: 4037.46 rows/s
 50 rows imported in 2 minutes and 3.058 seconds.
 {noformat}
 [jbellis] 7405 gets us almost an order of magnitude improvement.  
 Unfortunately we're still almost 2 orders slower than mysql.
 I don't think we can continue to tell people, use sstableloader instead.  
 The number of users sophisticated enough to use the sstable writers is small 
 and (relatively) decreasing as our user base expands.



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

[jira] [Commented] (CASSANDRA-8225) Production-capable COPY FROM


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

Aleksey Yeschenko commented on CASSANDRA-8225:
--

Is CSV even the primary source of imported data in C*? On common CSV-exported 
datasets, does 1 second vs 1 minute even matter?

Continuing to use COPY FROM + a java tool behind the scenes has its issues. 
COPY TO/FROM are being kept in sync wrt accepted formatting, and generally any 
cqlsh changes are reflected there. Now we'd have to emulate that logic in Java, 
too. And copy it first.

We also do still have CASSANDRA-7793 and CASSANDRA-7794 open. They won't give 
us anything close to a 200x improvement, but 1) they might get us to something 
acceptable and 2) they are relatively LHF.

Besides, since CASSANDRA-5894 it's not that complicated to write an 
sstablewriter.

So this would be nice to have, but I'm not sure the ROI is there.

 Production-capable COPY FROM
 

 Key: CASSANDRA-8225
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8225
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Reporter: Jonathan Ellis
 Fix For: 2.1.2


 Via [~schumacr],
 bq. I pulled down a sourceforge data generator and created a moc file of 
 500,000 rows that had an incrementing sequence number, date, and SSN. I then 
 used our COPY command and MySQL's LOAD DATA INFILE to load the file on my 
 Mac. Results were: 
 {noformat}
 mysql load data infile '/Users/robin/dev/datagen3.txt'  into table p_test  
 fields terminated by ',';
 Query OK, 50 rows affected (2.18 sec)
 {noformat}
 C* 2.1.0 (pre-CASSANDRA-7405)
 {noformat}
 cqlsh:dev copy p_test from '/Users/robin/dev/datagen3.txt' with 
 delimiter=',';
 50 rows imported in 16 minutes and 45.485 seconds.
 {noformat}
 Cassandra 2.1.1:
 {noformat}
 cqlsh:dev copy p_test from '/Users/robin/dev/datagen3.txt' with 
 delimiter=',';
 Processed 50 rows; Write: 4037.46 rows/s
 50 rows imported in 2 minutes and 3.058 seconds.
 {noformat}
 [jbellis] 7405 gets us almost an order of magnitude improvement.  
 Unfortunately we're still almost 2 orders slower than mysql.
 I don't think we can continue to tell people, use sstableloader instead.  
 The number of users sophisticated enough to use the sstable writers is small 
 and (relatively) decreasing as our user base expands.



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

[jira] [Commented] (CASSANDRA-8225) Production-capable COPY FROM


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

Aleksey Yeschenko commented on CASSANDRA-8225:
--

That, too.

 Production-capable COPY FROM
 

 Key: CASSANDRA-8225
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8225
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Reporter: Jonathan Ellis
 Fix For: 2.1.2


 Via [~schumacr],
 bq. I pulled down a sourceforge data generator and created a moc file of 
 500,000 rows that had an incrementing sequence number, date, and SSN. I then 
 used our COPY command and MySQL's LOAD DATA INFILE to load the file on my 
 Mac. Results were: 
 {noformat}
 mysql load data infile '/Users/robin/dev/datagen3.txt'  into table p_test  
 fields terminated by ',';
 Query OK, 50 rows affected (2.18 sec)
 {noformat}
 C* 2.1.0 (pre-CASSANDRA-7405)
 {noformat}
 cqlsh:dev copy p_test from '/Users/robin/dev/datagen3.txt' with 
 delimiter=',';
 50 rows imported in 16 minutes and 45.485 seconds.
 {noformat}
 Cassandra 2.1.1:
 {noformat}
 cqlsh:dev copy p_test from '/Users/robin/dev/datagen3.txt' with 
 delimiter=',';
 Processed 50 rows; Write: 4037.46 rows/s
 50 rows imported in 2 minutes and 3.058 seconds.
 {noformat}
 [jbellis] 7405 gets us almost an order of magnitude improvement.  
 Unfortunately we're still almost 2 orders slower than mysql.
 I don't think we can continue to tell people, use sstableloader instead.  
 The number of users sophisticated enough to use the sstable writers is small 
 and (relatively) decreasing as our user base expands.



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

[jira] [Commented] (CASSANDRA-8222) Unable to connect to any server with cqlsh

2014-10-30 Thread RADOMIRS CIRSKIS (JIRA)


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

RADOMIRS CIRSKIS commented on CASSANDRA-8222:
-

I have only one distribution on the machine (freshly cloned from git):

{noformat}
cqlsh --version  
cqlsh 5.0.1

cassandra -v
3.0.0-SNAPSHOT
{noformat}

 Unable to connect to any server with cqlsh
 

 Key: CASSANDRA-8222
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8222
 Project: Cassandra
  Issue Type: Bug
 Environment: java -version
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 python --version
 Python 2.7.8
Reporter: RADOMIRS CIRSKIS
  Labels: cqlsh

 I was going through the http://wiki.apache.org/cassandra/GettingStarted
 1. Installed cassandra
 2.  run cassandra: bin/cassandra -f
 3. in another terminal attempt to run cqlsh: cqlsh
 4. also I have tried explicitly: cqlsh 127.0.0.1 9042
 5. it produces a message:
 {noformat}
 Connection error: ('Unable to connect to any servers', {'127.0.0.1': 
 AttributeError('module' object has no attribute 'loads',)})
 {noformat}
 Cassandra is running and listening on the port 9042:
 {noformat}
 ...
 INFO  03:36:08 Using Netty Version: 
 [netty-buffer=netty-buffer-4.0.23.Final.208198c, 
 netty-codec=netty-codec-4.0.23.Final.208198c, 
 netty-codec-http=netty-codec-http-4.0.23.Final.208198c, 
 netty-codec-socks=netty-codec-socks-4.0.23.Final.208198c, 
 netty-common=netty-common-4.0.23.Final.208198c, 
 netty-handler=netty-handler-4.0.23.Final.208198c, 
 netty-transport=netty-transport-4.0.23.Final.208198c, 
 netty-transport-rxtx=netty-transport-rxtx-4.0.23.Final.208198c, 
 netty-transport-sctp=netty-transport-sctp-4.0.23.Final.208198c, 
 netty-transport-udt=netty-transport-udt-4.0.23.Final.208198c]
 INFO  03:36:08 Starting listening for CQL clients on 
 localhost/127.0.0.1:9042...
 INFO  03:36:09 Binding thrift service to localhost/127.0.0.1:9160
 INFO  03:36:09 Listening for thrift clients...
 {noformat}



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

[jira] [Commented] (CASSANDRA-7873) Replace AbstractRowResolver.replies with collection with tailored properties

2014-10-30 Thread Mikhail Stepura (JIRA)


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

Mikhail Stepura commented on CASSANDRA-7873:


I do confirm that bisect points to this ticket
{code}
✔ ~/Documents/workspace/cassandra [:691d530|…3⚑ 3]
16:02 $ git bisect good
b867050270408ed6cc77c03d78d75cce9799e38e is the first bad commit
commit b867050270408ed6cc77c03d78d75cce9799e38e
Author: Benedict Elliott Smith bened...@apache.org
Date:   Tue Sep 9 09:47:17 2014 +0700

Introduce new append-only concurrent collection, Accumulator, and use for 
AbstractRowResolver.replies

patch by benedict; reviewed by mishail for CASSANDRA-7873

:04 04 11bf5b20a94cdf411e43df48801bfda507838d20 
e705ba84008f188be5b462721367811c19465b7f M  src
{code}

 Replace AbstractRowResolver.replies with collection with tailored properties
 

 Key: CASSANDRA-7873
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7873
 Project: Cassandra
  Issue Type: Bug
 Environment: OSX and Ubuntu 14.04
Reporter: Philip Thompson
Assignee: Benedict
  Labels: qa-resolved
 Fix For: 3.0

 Attachments: 7873.21.txt, 7873.trunk.txt, 7873.txt


 The dtest auth_test.py:TestAuth.system_auth_ks_is_alterable_test is failing 
 on trunk only with the following stack trace:
 {code}
 Unexpected error in node1 node log:
 ERROR [Thrift:1] 2014-09-03 15:48:08,389 CustomTThreadPoolServer.java:219 - 
 Error occurred during processing of message.
 java.util.ConcurrentModificationException: null
   at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859) 
 ~[na:1.7.0_65]
   at java.util.ArrayList$Itr.next(ArrayList.java:831) ~[na:1.7.0_65]
   at 
 org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:71)
  ~[main/:na]
   at 
 org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:28)
  ~[main/:na]
   at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:110) 
 ~[main/:na]
   at 
 org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:144)
  ~[main/:na]
   at 
 org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1228) 
 ~[main/:na]
   at 
 org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1154) 
 ~[main/:na]
   at 
 org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:256)
  ~[main/:na]
   at 
 org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:212)
  ~[main/:na]
   at org.apache.cassandra.auth.Auth.selectUser(Auth.java:257) ~[main/:na]
   at org.apache.cassandra.auth.Auth.isExistingUser(Auth.java:76) 
 ~[main/:na]
   at org.apache.cassandra.service.ClientState.login(ClientState.java:178) 
 ~[main/:na]
   at 
 org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1486) 
 ~[main/:na]
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3579)
  ~[thrift/:na]
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3563)
  ~[thrift/:na]
   at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39) 
 ~[libthrift-0.9.1.jar:0.9.1]
   at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) 
 ~[libthrift-0.9.1.jar:0.9.1]
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:201)
  ~[main/:na]
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  [na:1.7.0_65]
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  [na:1.7.0_65]
   at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]
 {code}
 That exception is thrown when the following query is sent:
 {code}
 SELECT strategy_options
   FROM system.schema_keyspaces
   WHERE keyspace_name = 'system_auth'
 {code}
 The test alters the RF of the system_auth keyspace, then shuts down and 
 restarts the cluster.



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

[jira] [Commented] (CASSANDRA-7859) Extend freezing to collections

2014-10-30 Thread Tyler Hobbs (JIRA)


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

Tyler Hobbs commented on CASSANDRA-7859:


My branch has been updated.

bq. I'm not totally convinced about adding new Frozen*Type classes. It adds a 
bunch of code duplication and changes

The code duplication was only around extremely simple methods (field accessors, 
getInstance(), etc), so I felt it was worth it for the clarity.  But in any 
case, they have been removed as suggested, since I think that's reasonable as 
well.

bq. need to be a tad smarter when dealing with serializing/deserializing types

Good catch.  I've modified toString() for serialization, and added a 
mostly-fake FrozenType class that's only used for type parsing to address this 
(it seems simpler than special-casing TypeParser).

bq. The commit seems to include changes from CASSANDRA-6904, and some changes 
in StorageService/StreamCoordinator that are unrelated to this ticket.

Hmm, not sure how that happened.  I merged in the latest 2.1, so this should be 
resolved.

bq. I wonder if we shouldn't allow frozen on any type syntax wise. This would 
simply have no impact on simple types but that's already what happens for 
tuples after this patch so this would be somewhat consistent. I suspect this 
might simplify validation at least.

With the recent changes, that's what's effectively done internally now.  
However, I think allowing that in the syntax would be more confusing than 
helpful for users.  I can imagine a lot of questions like what's the 
difference between a frozen int and a non-frozen int?.  The fact that tuple 
has this behavior is just an unfortunate oddity, imo.

bq. In CQL3Type.Raw.RawCollection, in the prepare method, we could replace ...

Done

bq. I wonder if we shouldn't make it a bit more generic so that if we want to 
index full (frozen) UDT in the future we don't have to introduce a fullUDT and 
so on. What about generalizing to wholeValue (which is still a crappy name so 
better naming ideas welcome)?

We already support indexing complete (frozen) UDTs.  However, just shortening 
it to {{full()}} would be relatively clear, succinct, and flexible enough to 
cover other types if needed.

bq. In Tuples and UserTypes bindInternal methods, not sure using isMultiCell 
over the existing isCollection is a good idea.

Fixed, thanks.

bq. In SelectStatement.getRequestedColumns, the changes don't seem related to 
this issue, are they?

No, they aren't.  It's a bug that I discovered while working on this, and I 
intended to break that out into a separate ticket but forgot to.  I'll open a 
separate ticket as soon as I can remember exactly what the bug was :)

bq. In SelectStatement.buildBound, the !r.isContains() test is a no-op since ...

Fixed as suggested.

bq. In SingleColumnRestriction.Contains.canEvaluateWithSlices, I don't 
understand the comment.

It was just an idea for a potential future optimization.  It wasn't really 
useful, though, so it's been removed.

bq. Why do we need the newly added code in SecondaryIndexSearcher.validate?

We don't, removed.

bq. Note 100% sure about the isValueCompatible() for frozen collections...

Fair point.  It now uses {{isCompatible()}} for the name comparator.

 Extend freezing to collections
 --

 Key: CASSANDRA-7859
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7859
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Tyler Hobbs
  Labels: cql
 Fix For: 2.1.2

 Attachments: 7859-v1.txt


 This is the follow-up to CASSANDRA-7857, to extend {{frozen}} to collections. 
 This will allow things like {{maptext, frozenmapint, int}} for 
 instance, as well as allowing {{frozen}} collections in PK columns.
 Additionally (and that's alsmot a separate ticket but I figured we can start 
 discussing it here), we could decide that tuple is a frozen type by default. 
 This means that we would allow {{tupleint, text}} without needing to add 
 {{frozen}}, but we would require {{frozen}} for complex type inside tuple, so 
 {{tupleint, listtext}} would be rejected, but not {{tupleint, 
 frozenlisttext}}.



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

[jira] [Commented] (CASSANDRA-2356) make the debian package never start by default

2014-10-30 Thread Al Tobey (JIRA)


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

Al Tobey commented on CASSANDRA-2356:
-

Just about every operations / devops person I know dislikes the Debian policy 
for auto-starting and would rather services do not start on install.  It is 
compounded for us because a fresh install will get system tables initialized 
with a cluster name that is likely not useful, so not only do users have to 
stop the process, they also have to clean up the system tables.

BTW we don't have to add anything to /etc/default/cassandra to work around 
this. You can simply echo 'exit 0'  /etc/default/cassandra and it will do 
the same thing as long as shell-based init scripts are in play.

My preference is for disabling auto-start completely.

 make the debian package never start by default
 --

 Key: CASSANDRA-2356
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2356
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: Jeremy Hanna
Assignee: Michael Shuler
Priority: Minor
  Labels: debian, packaging
 Fix For: 3.0

 Attachments: 2356.txt


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



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

[jira] [Commented] (CASSANDRA-8004) Run LCS for both repaired and unrepaired data

2014-10-30 Thread Jeremiah Jordan (JIRA)


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

Jeremiah Jordan commented on CASSANDRA-8004:


One issue I seenis that this adds new required functions to abstract 
compactions strategy. Which will break 3rd party compaction strategies.

If we are going to be changing the interface, would it be better to have the 
wrapping strategy track the sstables and pass the list in?  Not sure how 
workable that is. 

 Run LCS for both repaired and unrepaired data
 -

 Key: CASSANDRA-8004
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8004
 Project: Cassandra
  Issue Type: Bug
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
  Labels: compaction
 Fix For: 2.1.2


 If a user has leveled compaction configured, we should run that for both the 
 unrepaired and the repaired data. I think this would make things a lot easier 
 for end users
 It would simplify migration to incremental repairs as well, if a user runs 
 incremental repair on its nice leveled unrepaired data, we wont need to drop 
 it all to L0, instead we can just start moving sstables from the unrepaired 
 leveling straight into the repaired leveling
 Idea could be to have two instances of LeveledCompactionStrategy and move 
 sstables between the instances after an incremental repair run (and let LCS 
 be totally oblivious to whether it handles repaired or unrepaired data). Same 
 should probably apply to any compaction strategy, run two instances and 
 remove all repaired/unrepaired logic from the strategy itself.



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

[jira] [Comment Edited] (CASSANDRA-8004) Run LCS for both repaired and unrepaired data

2014-10-30 Thread Jeremiah Jordan (JIRA)

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

Jeremiah Jordan edited comment on CASSANDRA-8004 at 10/31/14 12:14 AM:
---

One issue I see is that this adds new required functions to abstract
compactions strategy. Which will break 3rd party compaction strategies.

If we are going to be changing the interface, would it be better to have the
wrapping strategy track the sstables and pass the list in? Not sure how
workable that is.

was (Author: jjordan):
One issue I seenis that this adds new required functions to abstract
compactions strategy. Which will break 3rd party compaction strategies.

If we are going to be changing the interface, would it be better to have the
wrapping strategy track the sstables and pass the list in? Not sure how
workable that is.

Run LCS for both repaired and unrepaired data
-

Key: CASSANDRA-8004
URL: https://issues.apache.org/jira/browse/CASSANDRA-8004
Project: Cassandra
Issue Type: Bug
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
Labels: compaction
Fix For: 2.1.2

If a user has leveled compaction configured, we should run that for both the
unrepaired and the repaired data. I think this would make things a lot easier
for end users
It would simplify migration to incremental repairs as well, if a user runs
incremental repair on its nice leveled unrepaired data, we wont need to drop
it all to L0, instead we can just start moving sstables from the unrepaired
leveling straight into the repaired leveling
Idea could be to have two instances of LeveledCompactionStrategy and move
sstables between the instances after an incremental repair run (and let LCS
be totally oblivious to whether it handles repaired or unrepaired data). Same
should probably apply to any compaction strategy, run two instances and
remove all repaired/unrepaired logic from the strategy itself.

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

[jira] [Commented] (CASSANDRA-8222) Unable to connect to any server with cqlsh


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

Michael Shuler commented on CASSANDRA-8222:
---

That looks right. If your machine is running zero firewall rules (check that), 
does your machine happen to know its own name and localhost? DNS can be a 
fiddly thing.
{noformat}
mshuler@hana:~$ hostname
hana
mshuler@hana:~$ hostname -i
127.0.1.1
mshuler@hana:~$ host localhost
localhost has address 127.0.0.1
localhost has IPv6 address ::1
{noformat}

 Unable to connect to any server with cqlsh
 

 Key: CASSANDRA-8222
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8222
 Project: Cassandra
  Issue Type: Bug
 Environment: java -version
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 python --version
 Python 2.7.8
Reporter: RADOMIRS CIRSKIS
  Labels: cqlsh

 I was going through the http://wiki.apache.org/cassandra/GettingStarted
 1. Installed cassandra
 2.  run cassandra: bin/cassandra -f
 3. in another terminal attempt to run cqlsh: cqlsh
 4. also I have tried explicitly: cqlsh 127.0.0.1 9042
 5. it produces a message:
 {noformat}
 Connection error: ('Unable to connect to any servers', {'127.0.0.1': 
 AttributeError('module' object has no attribute 'loads',)})
 {noformat}
 Cassandra is running and listening on the port 9042:
 {noformat}
 ...
 INFO  03:36:08 Using Netty Version: 
 [netty-buffer=netty-buffer-4.0.23.Final.208198c, 
 netty-codec=netty-codec-4.0.23.Final.208198c, 
 netty-codec-http=netty-codec-http-4.0.23.Final.208198c, 
 netty-codec-socks=netty-codec-socks-4.0.23.Final.208198c, 
 netty-common=netty-common-4.0.23.Final.208198c, 
 netty-handler=netty-handler-4.0.23.Final.208198c, 
 netty-transport=netty-transport-4.0.23.Final.208198c, 
 netty-transport-rxtx=netty-transport-rxtx-4.0.23.Final.208198c, 
 netty-transport-sctp=netty-transport-sctp-4.0.23.Final.208198c, 
 netty-transport-udt=netty-transport-udt-4.0.23.Final.208198c]
 INFO  03:36:08 Starting listening for CQL clients on 
 localhost/127.0.0.1:9042...
 INFO  03:36:09 Binding thrift service to localhost/127.0.0.1:9160
 INFO  03:36:09 Listening for thrift clients...
 {noformat}



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

[jira] [Created] (CASSANDRA-8226) Cannot call a column 'timestamp'

2014-10-30 Thread Dave Cunningham (JIRA)

Dave Cunningham created CASSANDRA-8226:
--

 Summary: Cannot call a column 'timestamp'
 Key: CASSANDRA-8226
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8226
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native 
protocol v3]

Reporter: Dave Cunningham


create table test(date text, timestamp timeuuid, stuff text, PRIMARY KEY(date, 
timestamp));
insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
select * from test where date = '20141030' order by timestamp limit 1;
Traceback (most recent call last):
  File bin/cqlsh, line 861, in onecmd
self.handle_statement(st, statementtext)
  File bin/cqlsh, line 901, in handle_statement
return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
  File bin/cqlsh, line 910, in handle_parse_error
return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
  File bin/cqlsh, line 935, in perform_statement
result = self.perform_simple_statement(stmt)
  File bin/cqlsh, line 968, in perform_simple_statement
self.print_result(rows, self.parse_for_table_meta(statement.query_string))
  File bin/cqlsh, line 946, in parse_for_table_meta
parsed = cqlruleset.cql_parse(query_string)[1]
IndexError: list index out of range




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

[jira] [Updated] (CASSANDRA-8226) Cannot call a column 'timestamp'


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

T Jake Luciani updated CASSANDRA-8226:
--
Fix Version/s: 2.1.2

 Cannot call a column 'timestamp'
 

 Key: CASSANDRA-8226
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8226
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native 
 protocol v3]
Reporter: Dave Cunningham
 Fix For: 2.1.2


 create table test(date text, timestamp timeuuid, stuff text, PRIMARY 
 KEY(date, timestamp));
 insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
 insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
 insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
 select * from test where date = '20141030' order by timestamp limit 1;
 Traceback (most recent call last):
   File bin/cqlsh, line 861, in onecmd
 self.handle_statement(st, statementtext)
   File bin/cqlsh, line 901, in handle_statement
 return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
   File bin/cqlsh, line 910, in handle_parse_error
 return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
   File bin/cqlsh, line 935, in perform_statement
 result = self.perform_simple_statement(stmt)
   File bin/cqlsh, line 968, in perform_simple_statement
 self.print_result(rows, self.parse_for_table_meta(statement.query_string))
   File bin/cqlsh, line 946, in parse_for_table_meta
 parsed = cqlruleset.cql_parse(query_string)[1]
 IndexError: list index out of range



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

[jira] [Updated] (CASSANDRA-8226) Cannot call a column 'timestamp'


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

T Jake Luciani updated CASSANDRA-8226:
--
Priority: Minor  (was: Major)

 Cannot call a column 'timestamp'
 

 Key: CASSANDRA-8226
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8226
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native 
 protocol v3]
Reporter: Dave Cunningham
Priority: Minor
 Fix For: 2.1.2


 create table test(date text, timestamp timeuuid, stuff text, PRIMARY 
 KEY(date, timestamp));
 insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
 insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
 insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
 select * from test where date = '20141030' order by timestamp limit 1;
 Traceback (most recent call last):
   File bin/cqlsh, line 861, in onecmd
 self.handle_statement(st, statementtext)
   File bin/cqlsh, line 901, in handle_statement
 return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
   File bin/cqlsh, line 910, in handle_parse_error
 return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
   File bin/cqlsh, line 935, in perform_statement
 result = self.perform_simple_statement(stmt)
   File bin/cqlsh, line 968, in perform_simple_statement
 self.print_result(rows, self.parse_for_table_meta(statement.query_string))
   File bin/cqlsh, line 946, in parse_for_table_meta
 parsed = cqlruleset.cql_parse(query_string)[1]
 IndexError: list index out of range



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

[jira] [Resolved] (CASSANDRA-8198) http://www.apache.org/dist/cassandra/debian/dists/12x/main/binary-amd64/Packages is refering cassandra version 1.2.18, But the file cassandra_1.2.18_all.deb doesn't


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

T Jake Luciani resolved CASSANDRA-8198.
---
Resolution: Fixed

The repo is now showing 1.2.19 as latest. Reopen if you hit an issue.

 http://www.apache.org/dist/cassandra/debian/dists/12x/main/binary-amd64/Packages
  is refering cassandra version 1.2.18, But the file cassandra_1.2.18_all.deb 
 doesn't exist in 
 http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/
 

 Key: CASSANDRA-8198
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8198
 Project: Cassandra
  Issue Type: Bug
Reporter: papireddy
Assignee: T Jake Luciani
Priority: Minor





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

[jira] [Commented] (CASSANDRA-8008) Timed out waiting for timer thread on large stress command