[jira] [Commented] (CASSANDRA-4161) CQL 3.0 does not work in cqlsh with uppercase SELECT

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4161:


bq. I'm wondering why CQL is being parsed in the client at all? Couldn't we 
just handle the exceptions thrown by cassandra? That way we wouldn't have to 
keep cqlsh in sync with CQL development on the C*-side.

cqlsh has to attempt to parse input in order to recognize keyspace switches, 
provide tab-completion, implement the cqlsh-specific commands, separate 
multiple statements, and (in the future) to allow things like CASSANDRA-3799.

Yes, of course, if cqlsh can identify a CQL statement but can't parse it, and 
it doesn't recognize the command word as being cqlsh-specific, it should pass 
the CQL on untouched to Cassandra. The problem in this ticket was with cqlsh 
deciding incorrectly that the user intended to give a cqlsh-only command.

 CQL 3.0 does not work in cqlsh with uppercase SELECT
 

 Key: CASSANDRA-4161
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4161
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.1.0
 Environment: cqlsh
Reporter: Jonas Dohse
Priority: Minor
  Labels: cql3, cqlsh
 Attachments: 
 0001-Allow-CQL-3.0-with-uppercase-SELECT-statement.patch, 4161.patch.txt


 Uppercase SELECT prevents usage of CQL 3.0 features like ORDER BY
 Example:
 select * from test ORDER BY number; # works
 SELECT * from test ORDER BY number; # fails

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4161) CQL 3.0 does not work in cqlsh with uppercase SELECT

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4161:


+1 for 4161.patch.txt.

 CQL 3.0 does not work in cqlsh with uppercase SELECT
 

 Key: CASSANDRA-4161
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4161
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.1.0
 Environment: cqlsh
Reporter: Jonas Dohse
Priority: Minor
  Labels: cql3, cqlsh
 Attachments: 
 0001-Allow-CQL-3.0-with-uppercase-SELECT-statement.patch, 4161.patch.txt


 Uppercase SELECT prevents usage of CQL 3.0 features like ORDER BY
 Example:
 select * from test ORDER BY number; # works
 SELECT * from test ORDER BY number; # fails

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4163) CQL3 ALTER TABLE command causes NPE

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4163:


Link for the new tag (it's on the same branch, though):

http://github.com/thepaul/cassandra/tree/pending/4163-2

 CQL3 ALTER TABLE command causes NPE
 ---

 Key: CASSANDRA-4163
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4163
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: INFO 16:07:11,757 Cassandra version: 1.1.0-rc1-SNAPSHOT
 INFO 16:07:11,757 Thrift API version: 19.30.0
 INFO 16:07:11,758 CQL supported versions: 2.0.0,3.0.0-beta1 (default: 2.0.0)
Reporter: Kristine Hahn
Assignee: paul cannon
  Labels: cql3
 Fix For: 1.1.0

 Attachments: 4163.patch-2.txt, 4163.patch.txt


 To reproduce the problem:
 ./cqlsh --cql3
 Connected to Test Cluster at localhost:9160.
 [cqlsh 2.2.0 | Cassandra 1.1.0-rc1-SNAPSHOT | CQL spec 3.0.0 | Thrift 
 protocol 19.30.0]
 Use HELP for help.
 cqlsh CREATE KEYSPACE test34 WITH strategy_class = 
 'org.apache.cassandra.locator.SimpleStrategy' AND 
 strategy_options:replication_factor='1';
 cqlsh USE test34;
 cqlsh:test34 CREATE TABLE users (
   ... password varchar,
   ... gender varchar,
   ... session_token varchar,
   ... state varchar,
   ... birth_year bigint,
   ... pk varchar,
   ... PRIMARY KEY (pk)
   ... );
 cqlsh:test34 ALTER TABLE users ADD coupon_code varchar;
 TSocket read 0 bytes

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4173) cqlsh: in cql3 mode, use cql3 quoting when outputting cql

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4173:


No, it doesn't. Definitely that would have been easier.

 cqlsh: in cql3 mode, use cql3 quoting when outputting cql
 -

 Key: CASSANDRA-4173
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4173
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Affects Versions: 1.1.0
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cql3, cqlsh

 when cqlsh needs to output a column name or other term which needs quoting 
 (say, if you run DESCRIBE KEYSPACE and some column name has a space in it), 
 it currently only knows how to quote in the cql2 way. That is,
 {noformat}
 cqlsh:foo describe columnfamily bar
 CREATE COLUMNFAMILY bar (
   a int PRIMARY KEY,
   'b c' text
 ) WITH
 ...
 {noformat}
 cql3 does not recognize single quotes around column names, or columnfamily or 
 keyspace names either. cqlsh ought to learn how to use double-quotes instead 
 when in cql3 mode.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4163) CQL3 ALTER TABLE command causes NPE

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4163:


We could, in the grammar definition, but that attribute is only ever updated 
with an assignment, so the empty map would be consed for nothing. Hardly a big 
deal either way though.

 CQL3 ALTER TABLE command causes NPE
 ---

 Key: CASSANDRA-4163
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4163
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: INFO 16:07:11,757 Cassandra version: 1.1.0-rc1-SNAPSHOT
 INFO 16:07:11,757 Thrift API version: 19.30.0
 INFO 16:07:11,758 CQL supported versions: 2.0.0,3.0.0-beta1 (default: 2.0.0)
Reporter: Kristine Hahn
Assignee: paul cannon
  Labels: cql3
 Fix For: 1.1.0

 Attachments: 4163.patch.txt


 To reproduce the problem:
 ./cqlsh --cql3
 Connected to Test Cluster at localhost:9160.
 [cqlsh 2.2.0 | Cassandra 1.1.0-rc1-SNAPSHOT | CQL spec 3.0.0 | Thrift 
 protocol 19.30.0]
 Use HELP for help.
 cqlsh CREATE KEYSPACE test34 WITH strategy_class = 
 'org.apache.cassandra.locator.SimpleStrategy' AND 
 strategy_options:replication_factor='1';
 cqlsh USE test34;
 cqlsh:test34 CREATE TABLE users (
   ... password varchar,
   ... gender varchar,
   ... session_token varchar,
   ... state varchar,
   ... birth_year bigint,
   ... pk varchar,
   ... PRIMARY KEY (pk)
   ... );
 cqlsh:test34 ALTER TABLE users ADD coupon_code varchar;
 TSocket read 0 bytes

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4090) cqlsh can't handle python being a python3

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4090:


+1 from me.

 cqlsh can't handle python being a python3
 -

 Key: CASSANDRA-4090
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4090
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.0.8
 Environment: On Archlinux, where Python3 installations are default 
 (most distros currently use Python2 as default now)
 {code}
 $ ls -l `which python` 
 lrwxrwxrwx 1 root root 7 Nov 21 09:05 /usr/bin/python - python3
 {code}
Reporter: Andrew Ash
Assignee: Andrew Ash
 Attachments: 4090.patch.txt, python3-fix.patch


 cqlsh fails to run when {{python}} is a Python 3, with this error message:
 {code}
 andrew@spite:~/src/cassandra-trunk/bin $ ./cqlsh 
   File ./cqlsh, line 97
 except ImportError, e:
   ^
 SyntaxError: invalid syntax
 andrew@spite:~/src/cassandra-trunk/bin $ 
 {code}
 The error occurs because the cqlsh script checks for a default installation 
 of python that is older than a certain version, but not one newer that is 
 incompatible (e.g. Python3).  To fix this, I update the logic to only run 
 {{python}} if it's a version at least 2.5 but before 3.0  If this version of 
 python is in that range then role with it, otherwise try python2.6, 
 python2.7, then python2.5 (no change from before).
 This is working on my installation, where {{python}} executes python 3.2.2 
 and doesn't break backwards compatibility to distributions that haven't made 
 the jump to Python3 as default yet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3990) cqlsh support for CQL 3

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3990:


And as Eric mentioned, these expect the python-cql version in Cassandra to be 
updated to 1.0.10. My 3990 branch in github, tagged at:

https://github.com/thepaul/cassandra/tree/pending/3990

includes that python-cql update as well as the two commits attached here.

 cqlsh support for CQL 3
 ---

 Key: CASSANDRA-3990
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3990
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Eric Evans
Priority: Minor
 Fix For: 1.1.0

 Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt, 
 v2-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt, 
 v3-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt, 
 v3-0002-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt


 Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to 
 choose the cql version at launch time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3990) cqlsh support for CQL 3

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3990:


Sounds like the best thing is to have --cqlversion=VER along with --cql2 and 
--cql3 shortcuts.

 cqlsh support for CQL 3
 ---

 Key: CASSANDRA-3990
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3990
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Eric Evans
Priority: Minor
 Fix For: 1.1.0

 Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt, 
 v2-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt


 Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to 
 choose the cql version at launch time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4078:


Yuki- there is an index sstable with out-of-order keys, and that one could be 
fixed as you suggest, but the actual data sstable also has out-of-order keys.

 StackOverflowError when upgrading to 1.0.8 from 0.8.10
 --

 Key: CASSANDRA-4078
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.10
 Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
 May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
 Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
Reporter: Wenjun
Assignee: paul cannon
Priority: Critical
 Fix For: 0.8.10

 Attachments: 4078.add-asserts.txt, cassandra.yaml.1.0.8, 
 cassandra.yaml.8.10, keycheck.txt, system.log, system.log.0326, 
 system.log.0326-02


 Hello
 I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
 following exception when starting up 1.0.8.  We have been running 0.8.10 
 without any issues.
  
 Attached is the entire log file during startup of 1.0.8.  There are 2 
 exceptions:
 1. StackOverflowError (line 2599)
 2. InstanceAlreadyExistsException (line 3632)
 I tried run scrub under 0.8.10 first, it did not help.  Also, I tried 
 dropping the column family which caused the exception, it just got the same 
 exceptions from another column family.
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4078:


Oh, good. I'm glad that was doable.

Before we close the ticket, is there anything at all from your experience or 
Cassandra usage that may have been unusual- hardware, platform, storage method, 
custom data or index types, etc? I would really like at least to get some clues 
about how this happened, if possible.

 StackOverflowError when upgrading to 1.0.8 from 0.8.10
 --

 Key: CASSANDRA-4078
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.10
 Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
 May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
 Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
Reporter: Wenjun
Assignee: paul cannon
Priority: Critical
 Fix For: 0.8.10

 Attachments: 4078.add-asserts.txt, cassandra.yaml.1.0.8, 
 cassandra.yaml.8.10, keycheck.txt, system.log, system.log.0326, 
 system.log.0326-02


 Hello
 I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
 following exception when starting up 1.0.8.  We have been running 0.8.10 
 without any issues.
  
 Attached is the entire log file during startup of 1.0.8.  There are 2 
 exceptions:
 1. StackOverflowError (line 2599)
 2. InstanceAlreadyExistsException (line 3632)
 I tried run scrub under 0.8.10 first, it did not help.  Also, I tried 
 dropping the column family which caused the exception, it just got the same 
 exceptions from another column family.
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4078:


{noformat}
assert decoratedKey == null : Keys must not be null;
{noformat}

(-1)

 StackOverflowError when upgrading to 1.0.8 from 0.8.10
 --

 Key: CASSANDRA-4078
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.10
 Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
 May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
 Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
Reporter: Wenjun
Assignee: paul cannon
Priority: Minor
 Fix For: 1.0.10

 Attachments: 4078-asserts-v3.txt, 4078.add-asserts.txt, 
 4078.patch2.txt, cassandra.yaml.1.0.8, cassandra.yaml.8.10, keycheck.txt, 
 system.log, system.log.0326, system.log.0326-02


 Hello
 I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
 following exception when starting up 1.0.8.  We have been running 0.8.10 
 without any issues.
  
 Attached is the entire log file during startup of 1.0.8.  There are 2 
 exceptions:
 1. StackOverflowError (line 2599)
 2. InstanceAlreadyExistsException (line 3632)
 I tried run scrub under 0.8.10 first, it did not help.  Also, I tried 
 dropping the column family which caused the exception, it just got the same 
 exceptions from another column family.
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3990) cqlsh support for CQL 3

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3990:


You mean, a --cql2/-2 flag that's on by default for now, but can be used in a 
forward-compatible way as long as cql2 is supported?  I like that idea.

 cqlsh support for CQL 3
 ---

 Key: CASSANDRA-3990
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3990
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Eric Evans
Priority: Minor
 Fix For: 1.1.0

 Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt, 
 v2-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt


 Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to 
 choose the cql version at launch time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3990) cqlsh support for CQL 3

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3990:


bq. So in other words, we will later need to be able to distinguish between 
3.0.0 and 3.1.0.

Meaning there will be C* versions which support both? That seems wrong to me- 
if there's no major version increment, doesn't that mean 3.1.0 has to be 
backwards compatible with 3.0.0?

 cqlsh support for CQL 3
 ---

 Key: CASSANDRA-3990
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3990
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Eric Evans
Priority: Minor
 Fix For: 1.1.0

 Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt, 
 v2-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt


 Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to 
 choose the cql version at launch time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4078:


Wenjun- it would help at this point to be sure whether or not your sstables 
really do have keys which are out of order. Could you run the sstablekeys tool 
on the data file for that UserAgreementStatus CF? It looks like it is at 
{{/home/cassandra/var/lib/cassandra/data/Appoji/UserAgreementStatus/Appoji-UserAgreementStatus.userId-g-*-Data.db}}.
 We want to check that the byte sequences are in order:

{noformat}
$ for s in 
/home/cassandra/var/lib/cassandra/data/Appoji/UserAgreementStatus/Appoji-UserAgreementStatus.userId-g-*-{Data,Index}.db;
 do
 echo checking $s
 bin/sstablekeys $s | sort -c
 done
{noformat}

If that doesn't give any output, then maybe there really is a bug in the 
1.0/1.1 code that we need to look at.

 StackOverflowError when upgrading to 1.0.8 from 0.8.10
 --

 Key: CASSANDRA-4078
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.10
 Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
 May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
 Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
Reporter: Wenjun
Assignee: paul cannon
Priority: Critical
 Fix For: 0.8.10

 Attachments: 4078.add-asserts.txt, cassandra.yaml.1.0.8, 
 cassandra.yaml.8.10, system.log, system.log.0326, system.log.0326-02


 Hello
 I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
 following exception when starting up 1.0.8.  We have been running 0.8.10 
 without any issues.
  
 Attached is the entire log file during startup of 1.0.8.  There are 2 
 exceptions:
 1. StackOverflowError (line 2599)
 2. InstanceAlreadyExistsException (line 3632)
 I tried run scrub under 0.8.10 first, it did not help.  Also, I tried 
 dropping the column family which caused the exception, it just got the same 
 exceptions from another column family.
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4078:


Ok, so there are definitely out-of-order keys in your sstables. I have no good 
theories as to how that happened- I don't think anyone else has run into this. 
Were you possibly using any sort of custom types or parameterized types with 
0.8.9? Custom anything?

Either way, the thing to be done now is probably to get your data sorted. Maybe 
we can come up with a one-off tool of some kind to read the values and write 
them back out in a sorted way.

 StackOverflowError when upgrading to 1.0.8 from 0.8.10
 --

 Key: CASSANDRA-4078
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.10
 Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
 May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
 Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
Reporter: Wenjun
Assignee: paul cannon
Priority: Critical
 Fix For: 0.8.10

 Attachments: 4078.add-asserts.txt, cassandra.yaml.1.0.8, 
 cassandra.yaml.8.10, keycheck.txt, system.log, system.log.0326, 
 system.log.0326-02


 Hello
 I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
 following exception when starting up 1.0.8.  We have been running 0.8.10 
 without any issues.
  
 Attached is the entire log file during startup of 1.0.8.  There are 2 
 exceptions:
 1. StackOverflowError (line 2599)
 2. InstanceAlreadyExistsException (line 3632)
 I tried run scrub under 0.8.10 first, it did not help.  Also, I tried 
 dropping the column family which caused the exception, it just got the same 
 exceptions from another column family.
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3990) cqlsh support for CQL 3

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3990:


Cool. Do you think it's worth having an extra shortcut-y parameter like {{\-3}} 
or {{\-\-cql3}} instead of {{--cqlversion=3.0.0}}?

 cqlsh support for CQL 3
 ---

 Key: CASSANDRA-3990
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3990
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Eric Evans
Priority: Minor
 Fix For: 1.1.0

 Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt


 Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to 
 choose the cql version at launch time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4078:


Yeah, the problem is almost certainly either (a) some important difference in 
the way it's being used now versus the way it was used before, or (b) some sort 
of bug in 0.8.10. I don't think 1.0.8 or 1.1.0 are acting improperly given the 
data and configuration here; I'm just hoping I can help you sort out whatever 
datatype expectation mismatch or invalid sstables you have.

 StackOverflowError when upgrading to 1.0.8 from 0.8.10
 --

 Key: CASSANDRA-4078
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.10
 Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
 May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
 Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
Reporter: Wenjun
Assignee: paul cannon
Priority: Critical
 Fix For: 0.8.10

 Attachments: 4078.add-asserts.txt, cassandra.yaml.1.0.8, 
 cassandra.yaml.8.10, system.log, system.log.0326, system.log.0326-02


 Hello
 I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
 following exception when starting up 1.0.8.  We have been running 0.8.10 
 without any issues.
  
 Attached is the entire log file during startup of 1.0.8.  There are 2 
 exceptions:
 1. StackOverflowError (line 2599)
 2. InstanceAlreadyExistsException (line 3632)
 I tried run scrub under 0.8.10 first, it did not help.  Also, I tried 
 dropping the column family which caused the exception, it just got the same 
 exceptions from another column family.
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4078:


Wenjun, are you able to tell from the UUID keys shown which ColumnFamily is 
having these troubles? I can't quite tell for sure from the logs. If necessary, 
we can add more asserts to identify the right place, but we can skip that step 
if you already know which one it is.

 StackOverflowError when upgrading to 1.0.8 from 0.8.10
 --

 Key: CASSANDRA-4078
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.10
 Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
 May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
 Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
Reporter: Wenjun
Assignee: paul cannon
Priority: Critical
 Fix For: 0.8.10

 Attachments: 4078.add-asserts.txt, cassandra.yaml.1.0.8, 
 cassandra.yaml.8.10, system.log, system.log.0326, system.log.0326-02


 Hello
 I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
 following exception when starting up 1.0.8.  We have been running 0.8.10 
 without any issues.
  
 Attached is the entire log file during startup of 1.0.8.  There are 2 
 exceptions:
 1. StackOverflowError (line 2599)
 2. InstanceAlreadyExistsException (line 3632)
 I tried run scrub under 0.8.10 first, it did not help.  Also, I tried 
 dropping the column family which caused the exception, it just got the same 
 exceptions from another column family.
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4003) cqlsh still failing to handle decode errors in some column names

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4003:


Since i linked the previous tag, the new one is at 
https://github.com/thepaul/cassandra/tree/pending/4003-2 .

 cqlsh still failing to handle decode errors in some column names
 

 Key: CASSANDRA-4003
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4003
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.0.8
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cqlsh
 Fix For: 1.0.9

 Attachments: 4003-2.txt


 Columns which are expected to be text, but which are not valid utf8, cause 
 cqlsh to display an error and not show any output:
 {noformat}
 cqlsh:ks CREATE COLUMNFAMILY test (a text PRIMARY KEY) WITH comparator = 
 timestamp;
 cqlsh:ks INSERT INTO test (a, '2012-03-05') VALUES ('val1', 'val2');
 cqlsh:ks ASSUME test NAMES ARE text;
 cqlsh:ks select * from test;
 'utf8' codec can't decode byte 0xe1 in position 4: invalid continuation byte
 {noformat}
 the traceback with cqlsh --debug:
 {noformat}
 Traceback (most recent call last):
   File bin/cqlsh, line 581, in onecmd
 self.handle_statement(st)
   File bin/cqlsh, line 606, in handle_statement
 return custom_handler(parsed)
   File bin/cqlsh, line 663, in do_select
 self.perform_statement_as_tokens(parsed.matched, decoder=decoder)
   File bin/cqlsh, line 666, in perform_statement_as_tokens
 return self.perform_statement(cqlhandling.cql_detokenize(tokens), 
 decoder=decoder)
   File bin/cqlsh, line 693, in perform_statement
 self.print_result(self.cursor)
   File bin/cqlsh, line 728, in print_result
 self.print_static_result(cursor)
   File bin/cqlsh, line 742, in print_static_result
 formatted_names = map(self.myformat_colname, colnames)
   File bin/cqlsh, line 413, in myformat_colname
 wcwidth.wcswidth(name.decode(self.output_codec.name)))
   File /usr/local/Cellar/python/2.7.2/lib/python2.7/encodings/utf_8.py, 
 line 16, in decode
 return codecs.utf_8_decode(input, errors, True)
 UnicodeDecodeError: 'utf8' codec can't decode byte 0xe1 in position 4: 
 invalid continuation byte
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4083) cqlsh fails to list counter CF

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4083:


Item (1) is as intended; all current (at least all official) cassandra 
interfaces include row keys with only tombstone columns in them when fetching a 
range of keys. This behavior is apparently useful for some applications. 
Changing the behavior, or adding some sort of option or CQL syntax to omit 
those, would be doable but would need a separate dedicated JIRA ticket and some 
discussion.

I'll put in a fix for item (2).

 cqlsh fails to list counter CF
 --

 Key: CASSANDRA-4083
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4083
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.0.8
Reporter: Radim Kolar
Assignee: paul cannon

 1.
   These rows displayed are tombstones, they should not be displayed at all
 2. 
   It fails on first counter
 cqlsh select * from whois.ipbans;
  KEY,80.65.56.165
  KEY,ACA35681.ipt.aol.com
  KEY,204.229.100.77
  KEY,31.223.184.51
  KEY,75.144.148.1
  KEY,189.27.59.210
  KEY,111.191.88.7
  KEY,152.26.21.2
  KEY,81.43.98.238
  KEY,64.71.194.172
  KEY,189.83.117.145
  KEY,159.0.53.197
  KEY,190.236.203.195
  KEY,130.255.163.20
 Traceback (most recent call last):
   File /usr/local/bin/cqlsh, line 580, in onecmd
 self.handle_statement(st)
   File /usr/local/bin/cqlsh, line 605, in handle_statement
 return custom_handler(parsed)
   File /usr/local/bin/cqlsh, line 662, in do_select
 self.perform_statement_as_tokens(parsed.matched, decoder=decoder)
   File /usr/local/bin/cqlsh, line 665, in perform_statement_as_tokens
 return self.perform_statement(cqlhandling.cql_detokenize(tokens), 
 decoder=decoder)
   File /usr/local/bin/cqlsh, line 692, in perform_statement
 self.print_result(self.cursor)
   File /usr/local/bin/cqlsh, line 729, in print_result
 self.print_dynamic_result(cursor)
   File /usr/local/bin/cqlsh, line 764, in print_dynamic_result
 colvals = [self.myformat_value(val, casstype) for (val, casstype) in 
 zip(row, coltypes)]
   File /usr/local/bin/cqlsh, line 402, in myformat_value
 float_precision=self.display_float_precision)
   File /usr/local/bin/cqlsh, line 346, in format_value
 escapedval = val.replace('\\', '')
 AttributeError: 'int' object has no attribute 'replace'
 [default@whois] list ipbans;
 Using default limit of 100
 ---
 RowKey: 80.65.56.165
 ---
 RowKey: ACA35681.ipt.aol.com
 ---
 RowKey: 204.229.100.77
 ---
 RowKey: 31.223.184.51
 ---
 RowKey: 75.144.148.1
 ---
 RowKey: 189.27.59.210
 ---
 RowKey: 111.191.88.7
 ---
 RowKey: 152.26.21.2
 ---
 RowKey: 81.43.98.238
 ---
 RowKey: 64.71.194.172
 ---
 RowKey: 189.83.117.145
 ---
 RowKey: 159.0.53.197
 ---
 RowKey: 190.236.203.195
 ---
 RowKey: 130.255.163.20
 ---
 RowKey: 80.248.237.157
 = (counter=hits, value=4)
 ---
 create column family ipbans
  with column_type = 'Standard'
  and comparator = 'AsciiType'
  and default_validation_class = 'CounterColumnType'
  and key_validation_class = 'AsciiType'
  and rows_cached = 500.0
  and row_cache_save_period = 0
  and row_cache_keys_to_save = 2147483647
  and keys_cached = 5.0
  and key_cache_save_period = 14400
  and read_repair_chance = 0.2
  and gc_grace = 86400
  and min_compaction_threshold = 2
  and max_compaction_threshold = 32
  and replicate_on_write = true
  and row_cache_provider = 'ConcurrentLinkedHashCacheProvider'
  and compaction_strategy = 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
  and comment = 'number of queries per IP address'
  and column_metadata = [
{column_name : 'hits',
validation_class : CounterColumnType}];

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4078:


Ah, you got trunk by default (unstable code for future Cassandra 1.2). You need 
to do git checkout 4078 in that directory to switch to the 4078 branch.

 StackOverflowError when upgrading to 1.0.8 from 0.8.10
 --

 Key: CASSANDRA-4078
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.10
 Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
 May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
 Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
Reporter: Wenjun
Assignee: paul cannon
Priority: Critical
 Fix For: 0.8.10

 Attachments: 4078.add-asserts.txt, system.log, system.log.0326


 Hello
 I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
 following exception when starting up 1.0.8.  We have been running 0.8.10 
 without any issues.
  
 Attached is the entire log file during startup of 1.0.8.  There are 2 
 exceptions:
 1. StackOverflowError (line 2599)
 2. InstanceAlreadyExistsException (line 3632)
 I tried run scrub under 0.8.10 first, it did not help.  Also, I tried 
 dropping the column family which caused the exception, it just got the same 
 exceptions from another column family.
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4078:


Ok. It looks like there are indeed 6 places where something is trying to create 
an Interval where the min is  greater than the max. The following are taken 
from your log, right before the AssertionError, with some spaces added and 
other valid intervals cut out:

{noformat}
Interval(DecoratedKey(f3f31fef-9b24-4fe3-be8e-b54a43ccf867, 
f3f31fef9b244fe3be8eb54a43ccf867),
 DecoratedKey(62476171-4693-4a81-bd7c-01726bfca4c1, 
6247617146934a81bd7c01726bfca4c1)),
Interval(DecoratedKey(c60e0fbc-dcc6-472c-8d5c-8b3cd041e4c9, 
c60e0fbcdcc6472c8d5c8b3cd041e4c9),
 DecoratedKey(7dd77e1f-92e0-4bc7-a417-2f9b0b97170d, 
7dd77e1f92e04bc7a4172f9b0b97170d)),
Interval(DecoratedKey(920c1919-98c4-4da8-88da-325067f9ece3, 
920c191998c44da888da325067f9ece3),
 DecoratedKey(40d6f31d-4b37-492e-b06c-9de0088de83f, 
40d6f31d4b37492eb06c9de0088de83f)),
Interval(DecoratedKey(a5f8d3d8-d26a-47fd-904c-8d55784776fc, 
a5f8d3d8d26a47fd904c8d55784776fc),
 DecoratedKey(762f9402-e5f6-44bb-824c-f93170c2f508, 
762f9402e5f644bb824cf93170c2f508)),
Interval(DecoratedKey(a27d2f3b-8255-42fb-a8d5-5f0fe488dadb, 
a27d2f3b825542fba8d55f0fe488dadb),
 DecoratedKey(7582809c-34b3-4736-8dfe-19811303bbfa, 
7582809c34b347368dfe19811303bbfa)),
Interval(DecoratedKey(d72c5963-ebe8-4e13-a74b-5584ca1d053c, 
d72c5963ebe84e13a74b5584ca1d053c),
 DecoratedKey(4962307f-261d-469a-b48b-1de7cd7a7700, 
4962307f261d469ab48b1de7cd7a7700)),
{noformat}

This shouldn't ever happen, so I'll do some poking around to see where these 
come from.

 StackOverflowError when upgrading to 1.0.8 from 0.8.10
 --

 Key: CASSANDRA-4078
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.10
 Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
 May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
 Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
Reporter: Wenjun
Assignee: paul cannon
Priority: Critical
 Fix For: 0.8.10

 Attachments: 4078.add-asserts.txt, system.log, system.log.0326, 
 system.log.0326-02


 Hello
 I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
 following exception when starting up 1.0.8.  We have been running 0.8.10 
 without any issues.
  
 Attached is the entire log file during startup of 1.0.8.  There are 2 
 exceptions:
 1. StackOverflowError (line 2599)
 2. InstanceAlreadyExistsException (line 3632)
 I tried run scrub under 0.8.10 first, it did not help.  Also, I tried 
 dropping the column family which caused the exception, it just got the same 
 exceptions from another column family.
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4078:


These values come right from the SSTables. I've been looking through code to 
see if I can find any possibility of bad values being written to an SSTable, 
but there might be a simpler explanation:

Is there any possibility that you have configured a different partitioner for 
Cassandra 1.0.8 from the one you used when writing the SSTables (0.8.10, I 
suppose)?

 StackOverflowError when upgrading to 1.0.8 from 0.8.10
 --

 Key: CASSANDRA-4078
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.10
 Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
 May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
 Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
Reporter: Wenjun
Assignee: paul cannon
Priority: Critical
 Fix For: 0.8.10

 Attachments: 4078.add-asserts.txt, system.log, system.log.0326, 
 system.log.0326-02


 Hello
 I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
 following exception when starting up 1.0.8.  We have been running 0.8.10 
 without any issues.
  
 Attached is the entire log file during startup of 1.0.8.  There are 2 
 exceptions:
 1. StackOverflowError (line 2599)
 2. InstanceAlreadyExistsException (line 3632)
 I tried run scrub under 0.8.10 first, it did not help.  Also, I tried 
 dropping the column family which caused the exception, it just got the same 
 exceptions from another column family.
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4078:


Ok, looks like both are RandomPartitioner. I'll keep investigating.

 StackOverflowError when upgrading to 1.0.8 from 0.8.10
 --

 Key: CASSANDRA-4078
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.10
 Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
 May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
 Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
Reporter: Wenjun
Assignee: paul cannon
Priority: Critical
 Fix For: 0.8.10

 Attachments: 4078.add-asserts.txt, cassandra.yaml.1.0.8, 
 cassandra.yaml.8.10, system.log, system.log.0326, system.log.0326-02


 Hello
 I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
 following exception when starting up 1.0.8.  We have been running 0.8.10 
 without any issues.
  
 Attached is the entire log file during startup of 1.0.8.  There are 2 
 exceptions:
 1. StackOverflowError (line 2599)
 2. InstanceAlreadyExistsException (line 3632)
 I tried run scrub under 0.8.10 first, it did not help.  Also, I tried 
 dropping the column family which caused the exception, it just got the same 
 exceptions from another column family.
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4042) add caching to CQL CF options

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4042:


partial dupe of CASSANDRA-3941. I could remove caching from that one, or we 
could add bloom_filter_fp_chance to this one. I like the second option, since 
this looks pretty easy to add the other option to this already-done work.

 add caching to CQL CF options
 ---

 Key: CASSANDRA-4042
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4042
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Pavel Yaskevich
Assignee: Pavel Yaskevich
Priority: Minor
 Fix For: 1.1.0

 Attachments: CASSANDRA-4042.patch


 Caching option is missing from CQL ColumnFamily options.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4030) cql: support gc_grace seconds when creating a columnfamily

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4030:


{noformat}
CREATE COLUMNFAMILY gfdsa ( key blob PRIMARY KEY ) WITH gc_grace_seconds = 1200;
{noformat}

?

 cql: support gc_grace seconds when creating a columnfamily
 --

 Key: CASSANDRA-4030
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4030
 Project: Cassandra
  Issue Type: New Feature
Reporter: Tyler Patterson
Priority: Minor
  Labels: cql

 Add support for specifying gc_grace_seconds to CQL when creating column 
 families.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4024) cqlsh: Unicode characters break SELECT output for dynamic columnfamilies

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4024:


I'm pretty sure this is CASSANDRA-4003 again. Can you try this with the patch 
from there applied?

 cqlsh: Unicode characters break SELECT output for dynamic columnfamilies
 

 Key: CASSANDRA-4024
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4024
 Project: Cassandra
  Issue Type: Bug
 Environment: ubuntu, cqlsh from trunk
Reporter: Tyler Patterson
Assignee: paul cannon
  Labels: cql, cqlsh

 notice the 'æ' character in the second INSERT statement.
 {code}
 CREATE COLUMNFAMILY cf (KEY text primary key) WITH default_validation=text 
 AND comparator=text;
 INSERT INTO cf (KEY, col1) VALUES ('b', 'b');
 INSERT INTO cf (KEY, col2) VALUES ('a', 'æ');
 SELECT * FROM cf WHERE key in ('a', 'b');
 {code}
 When selecting back out this error happens:
 'ascii' codec can't decode byte 0xc3 in position 9: ordinal not in range(128)
 If the selection does not include a range of keys, then the error doesn't 
 happen. Also, different keys must be present in the output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4003) cqlsh still failing to handle decode errors in some column names

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4003:


Sure. Since the CQL driver deserializes column names before the client software 
(cqlsh) can see them, and does not expose the Cassandra data type for the 
column names, it was not always possible to determine from returned column 
names how they were meant to be interpreted. For example, it was sometimes 
impossible to tell TimeUUIDType from UUIDType, or any of the various integer or 
counter types apart, or even BytesType from AsciiType.

Cqlsh makes an effort to display data in the most meaningful form, and 
secondarily to visually distinguish data that would otherwise be too ambiguous 
using colors. So it needs to know the original column name type.

The CQL driver does not expose that, so this code uses internals to get it. 
Clearly it would make more sense to expose the info from the driver side, and I 
plan to do that, but it takes some extra process and testing. This hack is 
backwards compatible with older CQL driver versions, but possibly not 
forwards-compat.

Maybe it would be best to do a runtime check against the driver to see if it 
supports exposing column types before making this call.

 cqlsh still failing to handle decode errors in some column names
 

 Key: CASSANDRA-4003
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4003
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.0.8
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cqlsh
 Fix For: 1.0.9


 Columns which are expected to be text, but which are not valid utf8, cause 
 cqlsh to display an error and not show any output:
 {noformat}
 cqlsh:ks CREATE COLUMNFAMILY test (a text PRIMARY KEY) WITH comparator = 
 timestamp;
 cqlsh:ks INSERT INTO test (a, '2012-03-05') VALUES ('val1', 'val2');
 cqlsh:ks ASSUME test NAMES ARE text;
 cqlsh:ks select * from test;
 'utf8' codec can't decode byte 0xe1 in position 4: invalid continuation byte
 {noformat}
 the traceback with cqlsh --debug:
 {noformat}
 Traceback (most recent call last):
   File bin/cqlsh, line 581, in onecmd
 self.handle_statement(st)
   File bin/cqlsh, line 606, in handle_statement
 return custom_handler(parsed)
   File bin/cqlsh, line 663, in do_select
 self.perform_statement_as_tokens(parsed.matched, decoder=decoder)
   File bin/cqlsh, line 666, in perform_statement_as_tokens
 return self.perform_statement(cqlhandling.cql_detokenize(tokens), 
 decoder=decoder)
   File bin/cqlsh, line 693, in perform_statement
 self.print_result(self.cursor)
   File bin/cqlsh, line 728, in print_result
 self.print_static_result(cursor)
   File bin/cqlsh, line 742, in print_static_result
 formatted_names = map(self.myformat_colname, colnames)
   File bin/cqlsh, line 413, in myformat_colname
 wcwidth.wcswidth(name.decode(self.output_codec.name)))
   File /usr/local/Cellar/python/2.7.2/lib/python2.7/encodings/utf_8.py, 
 line 16, in decode
 return codecs.utf_8_decode(input, errors, True)
 UnicodeDecodeError: 'utf8' codec can't decode byte 0xe1 in position 4: 
 invalid continuation byte
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4003) cqlsh still failing to handle decode errors in some column names

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4003:


A fix is pushed to my 4003 github branch, also tagged at 
https://github.com/thepaul/cassandra/tree/pending/4003 .

 cqlsh still failing to handle decode errors in some column names
 

 Key: CASSANDRA-4003
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4003
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.0.8
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cqlsh
 Fix For: 1.0.9


 Columns which are expected to be text, but which are not valid utf8, cause 
 cqlsh to display an error and not show any output:
 {noformat}
 cqlsh:ks CREATE COLUMNFAMILY test (a text PRIMARY KEY) WITH comparator = 
 timestamp;
 cqlsh:ks INSERT INTO test (a, '2012-03-05') VALUES ('val1', 'val2');
 cqlsh:ks ASSUME test NAMES ARE text;
 cqlsh:ks select * from test;
 'utf8' codec can't decode byte 0xe1 in position 4: invalid continuation byte
 {noformat}
 the traceback with cqlsh --debug:
 {noformat}
 Traceback (most recent call last):
   File bin/cqlsh, line 581, in onecmd
 self.handle_statement(st)
   File bin/cqlsh, line 606, in handle_statement
 return custom_handler(parsed)
   File bin/cqlsh, line 663, in do_select
 self.perform_statement_as_tokens(parsed.matched, decoder=decoder)
   File bin/cqlsh, line 666, in perform_statement_as_tokens
 return self.perform_statement(cqlhandling.cql_detokenize(tokens), 
 decoder=decoder)
   File bin/cqlsh, line 693, in perform_statement
 self.print_result(self.cursor)
   File bin/cqlsh, line 728, in print_result
 self.print_static_result(cursor)
   File bin/cqlsh, line 742, in print_static_result
 formatted_names = map(self.myformat_colname, colnames)
   File bin/cqlsh, line 413, in myformat_colname
 wcwidth.wcswidth(name.decode(self.output_codec.name)))
   File /usr/local/Cellar/python/2.7.2/lib/python2.7/encodings/utf_8.py, 
 line 16, in decode
 return codecs.utf_8_decode(input, errors, True)
 UnicodeDecodeError: 'utf8' codec can't decode byte 0xe1 in position 4: 
 invalid continuation byte
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4002) cqlsh: error when selecting on certain column families

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-4002:


Tyler- could you try out the patch at CASSANDRA-4003? While these are 
technically different issues, the fix there was wide enough that it should fix 
this as well.

 cqlsh: error when selecting on certain column families
 --

 Key: CASSANDRA-4002
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4002
 Project: Cassandra
  Issue Type: Bug
 Environment: ubuntu and osx
Reporter: Tyler Patterson
Assignee: paul cannon

 Here are two examples that produce the error:
 {code}
 CREATE COLUMNFAMILY cf8 (KEY text PRIMARY KEY) WITH default_validation=uuid 
 AND comparator=uuid;
 INSERT INTO cf8 (KEY, '2097887f-53b2-4b89-bfb4-09fea6980d40', 
 'c3e990b5-238c-46f1-8c88-0267f5a5c446') VALUES ('76616c7565305f30', 
 '2097887f-53b2-4b89-bfb4-09fea6980d40', 
 'c3e990b5-238c-46f1-8c88-0267f5a5c446');
 select * from cf7 where KEY='76616c7565305f30';
 {code}
 produces the error: cannot concatenate 'str' and 'bool' objects
 {code}
 CREATE COLUMNFAMILY cf_blob_bool (KEY blob PRIMARY KEY) WITH 
 default_validation=boolean AND comparator=boolean;
 INSERT INTO cf_blob_bool (KEY, 'True', 'False') VALUES ('76616c7565305f30', 
 'True', 'False');
 select * from cf_blob_bool where KEY='76616c7565305f30';
 {code}
 produces the error: cannot concatenate 'str' and 'bool' objects

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3770) Timestamp datatype in CQL gets weird value?

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3770:


For the supported timestamp/date formats, see 
http://www.datastax.com/docs/1.0/references/cql/index#working-with-dates-and-times
 .

 Timestamp datatype in CQL gets weird value?
 ---

 Key: CASSANDRA-3770
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3770
 Project: Cassandra
  Issue Type: New Feature
 Environment: MacOS, Java
Reporter: Jawahar Prasad JP
Priority: Minor
  Labels: cql, java
 Fix For: 1.2


 Hi..
 I have created a columnfamily through CQL, having datatype as timestamp,
 I generate timestamp like this in Java:
 System.currentTimeMillis()
 (or)
 System.currentTimeMillis()*1000
 When I see the output through CQL, I get the data like below:
 1.32725062505e+12
 Also, I am not able to use any operators against this (like  '01 January 
 2012' etc.,), I get the below error:
 No indexed columns present in by-columns clause with equals operator
 But, I have created an index for the timestamp column.
 Any help ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3612) CQL inserting blank key.

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3612:


Ok, finally reproduced.  This isn't because there is more than one column with 
the blank key, it's because your second column (verified) must have an index 
on it. It's the read mutated indexes code path here that invokes the 
assertion for non-empty keys. You'll also see a similar traceback when trying 
to DELETE the row with the empty key.

And yes, QueryProcessor is missing validation for these write operations here 
(INSERT, UPDATE, DELETE, and each of those inside BATCH statements (would take 
a different validation path). QueryProcessor does have validation for most 
everything else, though.

 CQL inserting blank key.
 

 Key: CASSANDRA-3612
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3612
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0.0
 Environment: Linux ubuntu 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 
 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Reporter: samal
Assignee: paul cannon
Priority: Minor
  Labels: cql
 Fix For: 1.0.9


 One of our application bug inserted blank key into cluster causing assertion 
 error on key. After checking the root cause, I found it is the bug with CQL 
 and reproducible. Client cassandra-node and cqlsh-1.0.6.
 Blank key only work when one column provided.
  
 {}
 cqlsh insert into login (KEY,email)values('','');
 cqlsh select * from login;
 u'' | u'email',u'' 
 cqlsh insert into login (KEY,email,verified)values('','','');
 Request did not complete within rpc_timeout.
 cqlsh insert into login (KEY,verified)values('','');
 Request did not complete within rpc_timeout.
 cqlsh insert into login (KEY,email)values('','');
 cqlsh 
 cqlsh select * from login;
 u'' | u'email',u'' | u'uid',None
 cqlsh select * from login;
 u'' | u'email',u'' | u'uid',None
 cqlsh select * from login;
 u'' | u'email',u'' | u'uid',None
 cqlsh 
 cqlsh select * from login;
 u'' | u'email',u'' | u'uid',None
 u'samalgo...@gmail.com' | u'email',u'samalgo...@gmail.com' | 
 u'password',u'388ad1c312a488ee9e12998fe097f2258fa8d5ee' | 
 u'uid',UUID('05ea41dc-241f-11e1-8521-3da59237b189') | u'verified',u'0'
 cqlsh quit;
 {/}
 http://pastebin.com/HJn5fHhH

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3612) CQL inserting blank key.

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3612:


This particular problem is fixed in my github fork, in the 3612-1.0 and 
3612-1.1 branches.

https://github.com/thepaul/cassandra/commit/5dc73e765f - 3612-1.0
https://github.com/thepaul/cassandra/commit/eab19b0979 - 3612-1.1

However, it looks like problems of a similar nature still exist in cql3, in the 
1.1 series. I'll fix that and include those changes along with this ticket.

 CQL inserting blank key.
 

 Key: CASSANDRA-3612
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3612
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0.0
 Environment: Linux ubuntu 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 
 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Reporter: samal
Assignee: paul cannon
Priority: Minor
  Labels: cql
 Fix For: 1.0.9


 One of our application bug inserted blank key into cluster causing assertion 
 error on key. After checking the root cause, I found it is the bug with CQL 
 and reproducible. Client cassandra-node and cqlsh-1.0.6.
 Blank key only work when one column provided.
  
 {}
 cqlsh insert into login (KEY,email)values('','');
 cqlsh select * from login;
 u'' | u'email',u'' 
 cqlsh insert into login (KEY,email,verified)values('','','');
 Request did not complete within rpc_timeout.
 cqlsh insert into login (KEY,verified)values('','');
 Request did not complete within rpc_timeout.
 cqlsh insert into login (KEY,email)values('','');
 cqlsh 
 cqlsh select * from login;
 u'' | u'email',u'' | u'uid',None
 cqlsh select * from login;
 u'' | u'email',u'' | u'uid',None
 cqlsh select * from login;
 u'' | u'email',u'' | u'uid',None
 cqlsh 
 cqlsh select * from login;
 u'' | u'email',u'' | u'uid',None
 u'samalgo...@gmail.com' | u'email',u'samalgo...@gmail.com' | 
 u'password',u'388ad1c312a488ee9e12998fe097f2258fa8d5ee' | 
 u'uid',UUID('05ea41dc-241f-11e1-8521-3da59237b189') | u'verified',u'0'
 cqlsh quit;
 {/}
 http://pastebin.com/HJn5fHhH

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3767) cqlsh is missing cqlshlib (ImportError: No module named cqlshlib)

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3767:


Looks like the homebrew packaging neglects to ship all the necessary parts of 
cqlsh.

 cqlsh is missing cqlshlib (ImportError: No module named cqlshlib)
 -

 Key: CASSANDRA-3767
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3767
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.0.7
 Environment: Mac OS X 10.7.2 Snow Leopard
 Cassandra 1.0.7
 Installed using Homebrew
Reporter: Matthew O'Riordan
Assignee: paul cannon

 After a clean install of Cassandra, when running cqlsh I get the following 
 error:
 {code}cqlsh
 Traceback (most recent call last):
   File /usr/local/bin/cqlsh, line 54, in module
 from cqlshlib import cqlhandling, pylexotron
 ImportError: No module named cqlshlib
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2845) Cassandra uses 100% system CPU on Ubuntu Natty (11.04)

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-2845:


tyler- would it be possible to try with a 2.6.38-10 kernel, and/or try by 
running cassandra directly instead of with the initscript (which uses jsvc)? 
Also, which JVM are you using?

 Cassandra uses 100% system CPU on Ubuntu Natty (11.04)
 --

 Key: CASSANDRA-2845
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2845
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.0
 Environment: Default install of Ubuntu 11.04
Reporter: Steve Corona
Assignee: paul cannon
Priority: Critical
 Fix For: 0.8.2


 Step 1. Boot up a brand new, default Ubuntu 11.04 Server install
 Step 2. Install Cassandra from Apache APT Respository (deb 
 http://www.apache.org/dist/cassandra/debian 08x main)
 Step 3. apt-get install cassandra, as soon as it cassandra starts it will 
 freeze the machine
 What's happening is that as soon as cassandra starts up it immediately sucks 
 up 100% of CPU and starves the machine. This effectively bricks the box until 
 you boot into single user mode and disable the cassandra init.d script.
 Under htop, the CPU usage shows up as system cpu, not user.
 The machine I'm testing this on is a Quad-Core Sandy Bridge w/ 16GB of 
 Memory, so it's not a system resource issue. I've also tested this on 
 completely different hardware (Dual 64-Bit Xeons  AMD X4) and it has the 
 same effect.
 Ubuntu 10.10 does not exhibit the same issue. I have only tested 0.8 and 
 0.8.1.
 root@cassandra01:/# java -version
 java version 1.6.0_22
 OpenJDK Runtime Environment (IcedTea6 1.10.2) (6b22-1.10.2-0ubuntu1~11.04.1)
 OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
 root@cassandra:/# uname -a
 Linux cassandra01 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 
 2011 x86_64 x86_64 x86_64 GNU/Linux
 /proc/cpu
 Intel(R) Xeon(R) CPU E31270 @ 3.40GHz
 /proc/meminfo
 MemTotal:   16459776 kB
 MemFree:14190708 kB

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3767) cqlsh is missing cqlshlib (ImportError: No module named cqlshlib)

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3767:


Submitted https://github.com/mxcl/homebrew/pull/10353 ; we'll see what they 
think about that.

Merge my cqlsh-in-cassandra branch at g...@github.com:thepaul/homebrew.git into 
your Homebrew repo to get this fix earlier.

 cqlsh is missing cqlshlib (ImportError: No module named cqlshlib)
 -

 Key: CASSANDRA-3767
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3767
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.0.7
 Environment: Mac OS X 10.7.2 Snow Leopard
 Cassandra 1.0.7
 Installed using Homebrew
Reporter: Matthew O'Riordan
Assignee: paul cannon

 After a clean install of Cassandra, when running cqlsh I get the following 
 error:
 {code}cqlsh
 Traceback (most recent call last):
   File /usr/local/bin/cqlsh, line 54, in module
 from cqlshlib import cqlhandling, pylexotron
 ImportError: No module named cqlshlib
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3903) Intermittent unexpected errors: possibly race condition around CQL parser?

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3903:


O, I see. Derp. Thanks for the explanation.

I +1 these changes.

 Intermittent unexpected errors: possibly race condition around CQL parser?
 --

 Key: CASSANDRA-3903
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3903
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: Mac OS X 10.7 with Sun/Oracle Java 1.6.0_29
 Debian GNU/Linux 6.0.3 (squeeze) with Sun/Oracle Java 1.6.0_26
 several recent commits on cassandra-1.1 branch. at least:
 0183dc0b36e684082832de43a21b3dc0a9716d48, 
 3eefbac133c838db46faa6a91ba1f114192557ae, 
 9a842c7b317e6f1e6e156ccb531e34bb769c979f
 Running cassandra under ccm with one node
Reporter: paul cannon
Assignee: Sylvain Lebresne
 Attachments: 0001-Fix-CFS.all-thread-safety.patch, 
 0002-Fix-fixCFMaxId.patch


 When running multiple simultaneous instances of the test_cql.py piece of the 
 python-cql test suite, I can reliably reproduce intermittent and 
 unpredictable errors in the tests.
 The failures often occur at the point of keyspace creation during test setup, 
 with a CQL statement of the form:
 {code}
 CREATE KEYSPACE 'asnvzpot' WITH strategy_class = SimpleStrategy
 AND strategy_options:replication_factor = 1
 
 {code}
 An InvalidRequestException is returned to the cql driver, which re-raises it 
 as a cql.ProgrammingError. The message:
 {code}
 ProgrammingError: Bad Request: line 2:24 no viable alternative at input 
 'asnvzpot'
 {code}
 In a few cases, Cassandra threw an ArrayIndexOutOfBoundsException and this 
 traceback, closing the thrift connection:
 {code}
 ERROR [Thrift:244] 2012-02-10 15:51:46,815 CustomTThreadPoolServer.java (line 
 205) Error occurred during processing of message.
 java.lang.ArrayIndexOutOfBoundsException: 7
 at 
 org.apache.cassandra.db.ColumnFamilyStore.all(ColumnFamilyStore.java:1520)
 at 
 org.apache.cassandra.thrift.ThriftValidation.validateCfDef(ThriftValidation.java:634)
 at 
 org.apache.cassandra.cql.QueryProcessor.processStatement(QueryProcessor.java:744)
 at 
 org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:898)
 at 
 org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1245)
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3458)
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3446)
 at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
 at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
 at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:680)
 {code}
 Sometimes I see an ArrayOutOfBoundsError with no traceback:
 {code}
 ERROR [Thrift:858] 2012-02-13 12:04:01,537 CustomTThreadPoolServer.java (line 
 205) Error occurred during processing of message.
 java.lang.ArrayIndexOutOfBoundsException
 {code}
 Sometimes I get this:
 {code}
 ERROR [MigrationStage:1] 2012-02-13 12:04:46,077 AbstractCassandraDaemon.java 
 (line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
 java.lang.IllegalArgumentException: value already present: 1558
 at 
 com.google.common.base.Preconditions.checkArgument(Preconditions.java:115)
 at 
 com.google.common.collect.AbstractBiMap.putInBothMaps(AbstractBiMap.java:111)
 at com.google.common.collect.AbstractBiMap.put(AbstractBiMap.java:96)
 at com.google.common.collect.HashBiMap.put(HashBiMap.java:84)
 at org.apache.cassandra.config.Schema.load(Schema.java:392)
 at 
 org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:284)
 at 
 org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:209)
 at 
 org.apache.cassandra.db.migration.AddColumnFamily.applyImpl(AddColumnFamily.java:49)
 at 
 org.apache.cassandra.db.migration.Migration.apply(Migration.java:66)
 at 
 org.apache.cassandra.cql.QueryProcessor$1.call(QueryProcessor.java:334)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at 
 

[jira] [Commented] (CASSANDRA-3874) cqlsh: handle situation where data can't be deserialized as expected

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3874:


Changes made in my 3874-1.0 branch at github: 
https://github.com/thepaul/cassandra/tree/3874-1.0

Since the merge forward is not completely trivial, my 3874-1.1 branch has those 
commits already merged to 1.1: 
https://github.com/thepaul/cassandra/tree/3874-1.1 , and it will be an easy 
merge from that to your updated cassandra-1.1, whatever it is.

I'll attach patch versions too, in case you still prefer those.

 cqlsh: handle situation where data can't be deserialized as expected
 

 Key: CASSANDRA-3874
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3874
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cqlsh
 Fix For: 1.0.8


 When cqlsh tries to deserialize data which doesn't match the expected type 
 (either because the validation type for the column/key alias was changed, or 
 ASSUME has been used), it just fails completely and in most cases won't show 
 any results at all. When there is only one misbehaving value out of a large 
 number, this can be frustrating.
 cqlsh should either show some failure marker in place of the bad value, or 
 simply show the bytes along with some indicator of a failed deserialization.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3874) cqlsh: handle situation where data can't be deserialized as expected

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3874:


I think it's worth having in 1.0, especially if it's going to live for a few 
more releases. It's technically only a bugfix. But I don't mind much, whichever.

 cqlsh: handle situation where data can't be deserialized as expected
 

 Key: CASSANDRA-3874
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3874
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cqlsh
 Fix For: 1.0.8

 Attachments: 3874-1.0.patch.txt, 3874-1.1.patch.txt


 When cqlsh tries to deserialize data which doesn't match the expected type 
 (either because the validation type for the column/key alias was changed, or 
 ASSUME has been used), it just fails completely and in most cases won't show 
 any results at all. When there is only one misbehaving value out of a large 
 number, this can be frustrating.
 cqlsh should either show some failure marker in place of the bad value, or 
 simply show the bytes along with some indicator of a failed deserialization.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3874) cqlsh: handle situation where data can't be deserialized as expected

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3874:


updated the 3874-1.1 branch just now to add the 1.0.9 version of the python-cql 
library, since that is required for this fix to work. 1.0 doesn't have an 
embedded python-cql lib, so it's fine.

 cqlsh: handle situation where data can't be deserialized as expected
 

 Key: CASSANDRA-3874
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3874
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cqlsh
 Fix For: 1.0.8

 Attachments: 3874-1.0.patch.txt, 3874-1.1.patch.txt


 When cqlsh tries to deserialize data which doesn't match the expected type 
 (either because the validation type for the column/key alias was changed, or 
 ASSUME has been used), it just fails completely and in most cases won't show 
 any results at all. When there is only one misbehaving value out of a large 
 number, this can be frustrating.
 cqlsh should either show some failure marker in place of the bad value, or 
 simply show the bytes along with some indicator of a failed deserialization.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3903) Intermittent unexpected errors: possibly race condition around CQL parser?

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3903:


I should mention that I adjusted the python-cql tests to be able to run cleanly 
in parallel, in the parallel-tests branch.

 Intermittent unexpected errors: possibly race condition around CQL parser?
 --

 Key: CASSANDRA-3903
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3903
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: Mac OS X 10.7 with Sun/Oracle Java 1.6.0_29
 Debian GNU/Linux 6.0.3 (squeeze) with Sun/Oracle Java 1.6.0_26
 several recent commits on cassandra-1.1 branch. at least:
 0183dc0b36e684082832de43a21b3dc0a9716d48, 
 3eefbac133c838db46faa6a91ba1f114192557ae, 
 9a842c7b317e6f1e6e156ccb531e34bb769c979f
 Running cassandra under ccm with one node
Reporter: paul cannon

 When running multiple simultaneous instances of the test_cql.py piece of the 
 python-cql test suite, I can reliably reproduce intermittent and 
 unpredictable errors in the tests.
 The failures often occur at the point of keyspace creation during test setup, 
 with a CQL statement of the form:
 {code}
 CREATE KEYSPACE 'asnvzpot' WITH strategy_class = SimpleStrategy
 AND strategy_options:replication_factor = 1
 
 {code}
 An InvalidRequestException is returned to the cql driver, which re-raises it 
 as a cql.ProgrammingError. The message:
 {code}
 ProgrammingError: Bad Request: line 2:24 no viable alternative at input 
 'asnvzpot'
 {code}
 In a few cases, Cassandra threw an ArrayIndexOutOfBoundsException and this 
 traceback, closing the thrift connection:
 {code}
 ERROR [Thrift:244] 2012-02-10 15:51:46,815 CustomTThreadPoolServer.java (line 
 205) Error occurred during processing of message.
 java.lang.ArrayIndexOutOfBoundsException: 7
 at 
 org.apache.cassandra.db.ColumnFamilyStore.all(ColumnFamilyStore.java:1520)
 at 
 org.apache.cassandra.thrift.ThriftValidation.validateCfDef(ThriftValidation.java:634)
 at 
 org.apache.cassandra.cql.QueryProcessor.processStatement(QueryProcessor.java:744)
 at 
 org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:898)
 at 
 org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1245)
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3458)
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3446)
 at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
 at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
 at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:680)
 {code}
 Sometimes I see an ArrayOutOfBoundsError with no traceback:
 {code}
 ERROR [Thrift:858] 2012-02-13 12:04:01,537 CustomTThreadPoolServer.java (line 
 205) Error occurred during processing of message.
 java.lang.ArrayIndexOutOfBoundsException
 {code}
 Sometimes I get this:
 {code}
 ERROR [MigrationStage:1] 2012-02-13 12:04:46,077 AbstractCassandraDaemon.java 
 (line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
 java.lang.IllegalArgumentException: value already present: 1558
 at 
 com.google.common.base.Preconditions.checkArgument(Preconditions.java:115)
 at 
 com.google.common.collect.AbstractBiMap.putInBothMaps(AbstractBiMap.java:111)
 at com.google.common.collect.AbstractBiMap.put(AbstractBiMap.java:96)
 at com.google.common.collect.HashBiMap.put(HashBiMap.java:84)
 at org.apache.cassandra.config.Schema.load(Schema.java:392)
 at 
 org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:284)
 at 
 org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:209)
 at 
 org.apache.cassandra.db.migration.AddColumnFamily.applyImpl(AddColumnFamily.java:49)
 at 
 org.apache.cassandra.db.migration.Migration.apply(Migration.java:66)
 at 
 org.apache.cassandra.cql.QueryProcessor$1.call(QueryProcessor.java:334)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

[jira] [Commented] (CASSANDRA-3901) write endpoints are not treated correctly, breaking consistency guarantees

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3901:


I don't believe that the proposed fix for CASSANDRA-2434 covers these concerns 
at all.  I guess you could say that the *scope* of 2434 covers this, but I 
think it's separate enough to deserve its own ticket, as you've done.

 write endpoints are not treated correctly, breaking consistency guarantees
 --

 Key: CASSANDRA-3901
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3901
 Project: Cassandra
  Issue Type: Sub-task
  Components: Core
Reporter: Peter Schuller
Assignee: Peter Schuller
Priority: Critical

 I had a nagging feeling this was the case ever since I started wanting 
 CASSANDRA-3833 and thinking about hot to handle the association between nodes 
 in the read set and nodes in the write set.
 I may be wrong (please point me in the direct direction if so), but I see no 
 code anywhere that tries to (1) apply consistency level to currently normal 
 endpoints only, and (2) connect a given read endpoint with a future write 
 endpoint such that they are tied together for consistency purposes (parts of 
 these concerns probably is covered by CASSANDRA-2434 but that ticket is more 
 general).
 To be more clear about the problem: Suppose we have a ring of nodes, with a 
 single node bootstrapping. Now, for a given row key suppose reads are served 
 by A, B and C while writes are to go to A, B, C and D. In other words, D is 
 the node bootstrapping. Suppose RF is 3 and A,B,C,D is ring order. There are 
 a few things required for correct behavior:
 * Writes acked by D must never be treated as sufficient to satisfy 
 consistency level since until it is part of the read set it does not count 
 towards CL on reads.
 * Writes acked by B must *not* be treated as sufficient to satisfy 
 consistency level *unless* the same write is *also* acked by D, because once 
 D enters the ring, B will no longer be counting towards CL on reads. The only 
 alternative is to make the read succeed and disallow D from entering the ring.
 We don't seem to be handling this at all (and it becomes more complicated 
 with arbitrary transitions).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3639) Move streams too many data

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3639:


+1, although I agree the tests should probably move somewhere else. I worked a 
bit on putting similar tests in the dtest2 framework, and checking which ranges 
*actually* got streamed, but yeah, that's overkill for this.

I was a bit tripped up by the fact that {{calculateStreamAndFetchRanges}} is 
only valid for ranges for a moving node itself, and not for calculating changes 
for a remote node's movement (i.e., {{calculatePendingRanges}}), but that's ok, 
because it's only used in that way. A comment to that effect would not go 
amiss, though.

 Move streams too many data
 --

 Key: CASSANDRA-3639
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3639
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 0.8.7
Reporter: Fabien Rousseau
Priority: Minor
 Fix For: 1.1

 Attachments: 
 0001-try-to-fix-move-streaming-too-many-data-unit-tests-v2.patch, 
 0001-try-to-fix-move-streaming-too-many-data-unit-tests.patch


 During a move operation, we observed that the node streamed most of its data 
 and received all its data.
 We are running Cassandra 0.8.7 (plus a few patches)
 After reading the code related to move, we found out that :
  - in StorageService.java, line 2002 and line 2004 = ranges are returned in 
 a non ordered collection, but calculateStreamAndFetchRanges() method (line 
 2011) assume ranges are sorted, thus, resulting in wider ranges to be 
 fetched/streamed
 We managed to isolate and reproduce this in a unit test.
 We also propose a patch which :
  - does not rely on any sort
  - adds a few unit tests (may not be exhaustive...)
 Unit tests are done only for RF=2 and for the OldNetworkStrategyTopology. 
 For the sake of simplicity, we've put them in OldNetworkStrategyTopologyTest, 
 but they probably should be moved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3781) CQL support for altering key_validation_class in ALTER TABLE

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3781:


Sylvain- it looks like this patch changes the default_validation_class instead 
of the key_validation_class in the cql2 case. The default_validation_class can 
already be changed through CQL.

Other than that one s/setDefault/setKey/ change, +1

 CQL support for altering key_validation_class in ALTER TABLE
 

 Key: CASSANDRA-3781
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3781
 Project: Cassandra
  Issue Type: Improvement
Reporter: Rick Branson
Assignee: Sylvain Lebresne
 Fix For: 1.1

 Attachments: 3781.patch


 There is currently no way to alter the key_validation_class from CQL. jbellis 
 suggested that this could be done by being able to ALTER the type of the KEY 
 alias.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2434) range movements can violate consistency

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-2434:


So, I believe that the rules outlined above can still work without the wait X 
seconds between bootstrap operations prereq, if a pretty simple extra step is 
added:

If any node learns about conflicting move operations, then some rules are 
applied to choose which will be honored and which will return an error to its 
caller (if still possible).

Those rules are:
* A decom for node X beats a move or bootstrap for node X
* Two decoms for node X from coordinator nodes Y and Z: the coordinator with 
the higher token wins
* Any other conflicts between move/bootstrap operations for the same node 
(which can arise in certain partition situations) are easily resolved by latest 
VersionedValue.

This should guarantee convergence of TokenMetadata across any affected parts of 
a cluster.

 range movements can violate consistency
 ---

 Key: CASSANDRA-2434
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2434
 Project: Cassandra
  Issue Type: Bug
Reporter: Peter Schuller
Assignee: paul cannon
 Fix For: 1.1

 Attachments: 2434-3.patch.txt, 2434-testery.patch.txt


 My reading (a while ago) of the code indicates that there is no logic 
 involved during bootstrapping that avoids consistency level violations. If I 
 recall correctly it just grabs neighbors that are currently up.
 There are at least two issues I have with this behavior:
 * If I have a cluster where I have applications relying on QUORUM with RF=3, 
 and bootstrapping complete based on only one node, I have just violated the 
 supposedly guaranteed consistency semantics of the cluster.
 * Nodes can flap up and down at any time, so even if a human takes care to 
 look at which nodes are up and things about it carefully before 
 bootstrapping, there's no guarantee.
 A complication is that not only does it depend on use-case where this is an 
 issue (if all you ever do you do at CL.ONE, it's fine); even in a cluster 
 which is otherwise used for QUORUM operations you may wish to accept 
 less-than-quorum nodes during bootstrap in various emergency situations.
 A potential easy fix is to have bootstrap take an argument which is the 
 number of hosts to bootstrap from, or to assume QUORUM if none is given.
 (A related concern is bootstrapping across data centers. You may *want* to 
 bootstrap to a local node and then do a repair to avoid sending loads of data 
 across DC:s while still achieving consistency. Or even if you don't care 
 about the consistency issues, I don't think there is currently a way to 
 bootstrap from local nodes only.)
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3374) CQL can't create column with compression or that use leveled compaction

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3374:


+1

 CQL can't create column with compression or that use leveled compaction
 ---

 Key: CASSANDRA-3374
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3374
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0.0
Reporter: Sylvain Lebresne
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 1.0.8

 Attachments: CASSANDRA-3374-compaction_strategy_class.patch, 
 CASSANDRA-3374.patch


 Looking at CreateColumnFamilyStatement.java, it doesn't seem CQL can create 
 compressed column families, nor define a compaction strategy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3781) CQL support for altering key_validation_class in ALTER TABLE

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3781:


I thought we just decided recently that it was too dangerous to allow changing 
the key comparator?

 CQL support for altering key_validation_class in ALTER TABLE
 

 Key: CASSANDRA-3781
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3781
 Project: Cassandra
  Issue Type: Improvement
Reporter: Rick Branson
Assignee: Sylvain Lebresne
 Fix For: 1.1

 Attachments: 3781.patch


 There is currently no way to alter the key_validation_class from CQL. jbellis 
 suggested that this could be done by being able to ALTER the type of the KEY 
 alias.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3764) cqlsh doesn't error out immediately for use of invalid keyspace

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3764:


+1

 cqlsh doesn't error out immediately for use of invalid keyspace
 ---

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

 Attachments: 3764.txt


 {noformat}
 cqlsh use wordcoun;
 cqlsh:wordcoun select * from input_words;
 Bad Request: Keyspace wordcoun does not exist
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3759) [patch] don't allow dropping the system keyspace

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3759:


bq. We require keyspace to be set, to create keyspaces?

I would hope not. We didn't before.

 [patch] don't allow dropping the system keyspace
 

 Key: CASSANDRA-3759
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3759
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Dave Brosius
Assignee: Dave Brosius
Priority: Trivial
 Fix For: 1.0.8

 Attachments: CASSANDRA-3759-npe-fix.patch, no_drop_system.diff


 throw an IRE if user attempts to drop system keyspace

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3759) [patch] don't allow dropping the system keyspace

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3759:


Looks like the patch fixed thrift (and thereby cli). CQL still broken.

 [patch] don't allow dropping the system keyspace
 

 Key: CASSANDRA-3759
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3759
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Dave Brosius
Assignee: Dave Brosius
Priority: Trivial
 Fix For: 1.0.8

 Attachments: CASSANDRA-3759-npe-fix.patch, no_drop_system.diff


 throw an IRE if user attempts to drop system keyspace

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3759) [patch] don't allow dropping the system keyspace

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3759:


+1

 [patch] don't allow dropping the system keyspace
 

 Key: CASSANDRA-3759
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3759
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Dave Brosius
Assignee: Dave Brosius
Priority: Trivial
 Fix For: 1.0.8

 Attachments: CASSANDRA-3759-fix-create-update-drop-keyspaces.patch, 
 CASSANDRA-3759-npe-fix.patch, no_drop_system.diff


 throw an IRE if user attempts to drop system keyspace

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3764) cqlsh doesn't error out immediately for use of invalid keyspace

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3764:


I always thought this was expected behavior. Is there any chance this might 
break some existing code? I guess probably not.

 cqlsh doesn't error out immediately for use of invalid keyspace
 ---

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

 Attachments: 3764.txt


 {noformat}
 cqlsh use wordcoun;
 cqlsh:wordcoun select * from input_words;
 Bad Request: Keyspace wordcoun does not exist
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


In the absence of further input, I'll go ahead with the remove both 
cassandra-cli and cqlsh from the tree and package them separately for 
rpm/deb/tarball plan.

Let the record show that I would still prefer shipping a private copy of 
python-cql, as long as the main modus operandi for c* is bundle all 
requirements. :P

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cql, cqlsh
 Fix For: 1.1


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


bq. But -1 on going to extra effort to obfuscate the cql driver.

I was thinking just rename the egg in lib/ something like 
python-cql-internal-only.egg. Not a whole lot of effort involved, and it 
communicates the intent.

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cql, cqlsh
 Fix For: 1.1


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3726) cqlsh and cassandra-cli show keys differently for data created via stress tool

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3726:


sys.stdout can change, yeah, and that might happen depending on how we decide 
to implement output capture vis à vis CASSANDRA-3479. Note that's different 
from just dup2-ing another stream onto fd 0.

bq. 1e6defcaba90b7313d87c2626cbb6ae418b40567 still doesn't apply cleanly to 1.0 
for me.

Are you sure? Its only parent is fc6103966cbe90c96e75f4b52c10376b9df468d7, 
which is currently the head of cassandra-1.0 on the git-wip-us.apache.org repo.

 cqlsh and cassandra-cli show keys differently for data created via stress tool
 --

 Key: CASSANDRA-3726
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3726
 Project: Cassandra
  Issue Type: Bug
Reporter: Cathy Daw
Assignee: paul cannon
Priority: Minor
 Attachments: 3726.patch.2.txt


 {code}
 // Run: stress --operation=INSERT --num-keys=5  --columns=2 
 --consistency-level=QUORUM --column-size=1 --threads=1 --replication-factor=1 
 --nodes=localhost
 // cqlsh
 cqlsh:Keyspace1 select * from Standard1;
  KEY,3 | C0,c | C1,c | 
  KEY,0 | 
  KEY,2 | C0,c | C1,c | 
  KEY,1 | C0,c | C1,c | 
  KEY,4 | C0,c | C1,c | 
 cqlsh:Keyspace1 describe columnfamily Standard1;
 CREATE COLUMNFAMILY Standard1 (
   KEY blob PRIMARY KEY
 ) WITH
   comment='' AND
   comparator=ascii AND
   row_cache_provider='ConcurrentLinkedHashCacheProvider' AND
   key_cache_size=20.00 AND
   row_cache_size=0.00 AND
   read_repair_chance=1.00 AND
   gc_grace_seconds=864000 AND
   default_validation=blob AND
   min_compaction_threshold=4 AND
   max_compaction_threshold=32 AND
   row_cache_save_period_in_seconds=0 AND
   key_cache_save_period_in_seconds=14400 AND
   replicate_on_write=True;
 // cassandra-cli
 [default@Keyspace1] list Standard1;
 Using default limit of 100
 ---
 RowKey: 33
 = (column=C0, value=63, timestamp=1326259960705)
 = (column=C1, value=63, timestamp=1326259960705)
 ---
 RowKey: 30
 ---
 RowKey: 32
 = (column=C0, value=63, timestamp=1326259960704)
 = (column=C1, value=63, timestamp=1326259960704)
 ---
 RowKey: 31
 = (column=C0, value=63, timestamp=1326259960704)
 = (column=C1, value=63, timestamp=1326259960704)
 ---
 RowKey: 34
 = (column=C0, value=63, timestamp=1326259960705)
 = (column=C1, value=63, timestamp=1326259960705)
 [default@Keyspace1] describe Standard1;
 ColumnFamily: Standard1
   Key Validation Class: org.apache.cassandra.db.marshal.BytesType
   Default column value validator: 
 org.apache.cassandra.db.marshal.BytesType
   Columns sorted by: org.apache.cassandra.db.marshal.AsciiType
   Row cache size / save period in seconds / keys to save : 0.0/0/all
   Row Cache Provider: 
 org.apache.cassandra.cache.ConcurrentLinkedHashCacheProvider
   Key cache size / save period in seconds: 20.0/14400
   GC grace seconds: 864000
   Compaction min/max thresholds: 4/32
   Read repair chance: 1.0
   Replicate on write: true
   Built indexes: []
   Compaction Strategy: 
 org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3636) cassandra 1.0.6 debian packages will not run on OpenVZ

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3636:


Saulius- are you also running openvz? What version, if so?

 cassandra 1.0.6 debian packages will not run on OpenVZ
 --

 Key: CASSANDRA-3636
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3636
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Affects Versions: 1.0.6
 Environment: Debian Linux (stable), OpenVZ container
Reporter: Zenek Kraweznik
Assignee: Brandon Williams
Priority: Minor

 During upgrade from 1.0.6
 {code}Setting up cassandra (1.0.6) ...
 *error: permission denied on key 'vm.max_map_count'*
 dpkg: error processing cassandra (--configure):
  subprocess installed post-installation script returned error exit status 255
 Errors were encountered while processing:
  cassandra
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


Whatever we're going to do here for 1.1, we probably want to get started. Is 
there any further input? In particular, will C* lose points if it gets 
distributed (as a tarball, at least) without any client software?

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cql, cqlsh
 Fix For: 1.1


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-2474:


bq. I do have my own minor gripe about this, actually, which is that single 
quotes means string literal to SQL. We should stick to double quotes when we 
need identifier disambiguation.

Except in SQL, integers, floats, uuids, etc., aren't valid column names. CQL 
already supports using (quoted) string literals as column names, which seems 
like it would be useful for disambiguating text column names that might 
otherwise parse as integers or whatever. It seems more natural to keep the 
string-literal notation used everywhere else in the language intact for column 
names.

Maybe this is no longer important with the new semantics, though. Haven't 
thought it through yet.

 CQL support for compound columns and wide rows
 --

 Key: CASSANDRA-2474
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
Priority: Critical
  Labels: cql
 Fix For: 1.1

 Attachments: 0001-Add-support-for-wide-and-composite-CFs.patch, 
 0002-thrift-generated-code.patch, 2474-transposed-1.PNG, 
 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 
 2474-transposed-select.PNG, cql_tests.py, raw_composite.txt, 
 screenshot-1.jpg, screenshot-2.jpg


 For the most part, this boils down to supporting the specification of 
 compound column names (the CQL syntax is colon-delimted terms), and then 
 teaching the decoders (drivers) to create structures from the results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-2474:


bq. I'll also note that this patch (with the things above) make it so that in 
the CqlMetadata (in the result), the name_types are not useful anymore (since 
this is always UTF8), and neither is the default comparator and default 
validation types, as we can always set the type of each columns in the 
value_types map. I suppose the best way to proceed is to mark them deprecated 
for now and remove them in the next version.

This seems possibly too far. Clients ought to be able to know what a CF's 
default comparator and validation types are, even if they're not necessary to 
deserialize column values.

Also, cqlsh has an ASSUME facility similar to the cli one. You can tell cqlsh 
to deserialize columns without an explicit column type as though they were 
something different. Would this still be possible without being able to tell 
whether column values had an explicit column_metadata type, or whether they 
were using the default?

 CQL support for compound columns and wide rows
 --

 Key: CASSANDRA-2474
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
Priority: Critical
  Labels: cql
 Fix For: 1.1

 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 
 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, 
 cql_tests.py, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg


 For the most part, this boils down to supporting the specification of 
 compound column names (the CQL syntax is colon-delimted terms), and then 
 teaching the decoders (drivers) to create structures from the results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-2474:


bq. I don't see any problem to having an ASSUME facility with what I'm 
proposing. Maybe it will be more clear with the patch, but I really thing that 
after the patch those info adds really no value to the resultSet.

Example:

{noformat}
CREATE COLUMNFAMILY columnfam (keyname uuid PRIMARY KEY, username utf8) WITH 
default_validation = blob;
ASSUME columnfam VALUES ARE float;
{noformat}

In this situation, cqlsh should deserialize 'keyname' values as uuid, and 
'username' values as utf8, but any other column values should be deserialized 
as float. cqlsh currently makes the distinction by seeing whether the type for 
a value is given in the CqlMetadata.value_types field. It sounds like your 
proposal involves sending a type for every column in the result; am I 
misinterpreting that?

I guess cqlsh could query the columnfamily options itself whenever it needed to 
determine the default_validation, but that seems like it kind of makes 
CqlMetadata useless.

 CQL support for compound columns and wide rows
 --

 Key: CASSANDRA-2474
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
Priority: Critical
  Labels: cql
 Fix For: 1.1

 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 
 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, 
 cql_tests.py, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg


 For the most part, this boils down to supporting the specification of 
 compound column names (the CQL syntax is colon-delimted terms), and then 
 teaching the decoders (drivers) to create structures from the results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3101) Should check for errors when calling /bin/ln

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3101:


aha, thanks for clarification.

 Should check for errors when calling /bin/ln
 

 Key: CASSANDRA-3101
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3101
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.4
Reporter: paul cannon
Assignee: Vijay
Priority: Minor
  Labels: lhf
 Fix For: 1.0.7

 Attachments: 0001-0001-throw-IOE-while-calling-bin-ln-v2.patch, 
 0001-3101-throw-IOE-while-calling-bin-ln-v3.patch, 
 0001-3101-throw-IOE-while-calling-bin-ln.patch


 It looks like cassandra.utils.CLibrary.createHardLinkWithExec() does not 
 check for any errors in the execution of the hard-link-making utility. This 
 could be bad if, for example, the user has put the snapshot directory on a 
 different filesystem from the data directory. The hard linking would fail and 
 the sstable snapshots would not exist, but no error would be reported.
 It does look like errors with the more direct JNA link() call are handled 
 correctly- an exception is thrown. The WithExec version should probably do 
 the same thing.
 Definitely it would be enough to check the process exit value from /bin/ln 
 for nonzero in the *nix case, but I don't know whether 'fsutil hardlink 
 create' or 'cmd /c mklink /H' return nonzero on failure.
 For bonus points, use any output from the Process's error stream in the text 
 of the exception, to aid in debugging problems.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3707) Add KeyspaceChange CqlResultType

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3707:


bq. How about returning both current KS and CF in the metadata response on all 
requests?

If all requests here includes USE instructions, then that would solve the 
problem too. It doesn't seem to add much value, though; load-balancing client 
libraries would need to keep track of the current keyspace per connection 
either way.

 Add KeyspaceChange CqlResultType
 

 Key: CASSANDRA-3707
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3707
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Jonathan Ellis
Priority: Minor
  Labels: cql
 Fix For: 1.1


 High level clients want to handle failover and load balancing transparently 
 to the application, which means not just connection pooling but moving an 
 existing connection to another server if necessary.  When this happens, the 
 client needs to know what the active keyspace was before failover, so it can 
 set it to the same one in the new connection.
 Currently some clients handle this by checking for SET KEYSPACE queries, 
 which violates the design principle that clients shouldn't have to parse CQL. 
  Adding a new CqlResultType (that is set in response to a SET KEYSPACE 
 command) would make this unnecessary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


bq. I feel like I missed something important. The description called for 
bundling a private copy of the driver. This seems to be identical to how we 
currently handle all of our other external dependencies. Is that off the table 
now?

No, it's not off the table, but it's moot unless we decide we want cqlsh 
in-tree at all.

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Blocker
  Labels: cql, cqlsh
 Fix For: 1.0.7


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


bq. And to try to sum up my 'depency' bits above in debian terms, what I meant 
is that if cqlsh is in-tree, then we'll have a 'depends: python-cql', while if 
it is a separate project, we'll have a 'recommends: cqlsh' (and cqlsh will 
'depends: python-cql')

I did understand what you meant, but I disagree here- I don't think putting 
cqlsh in-tree or not has much effect on whether we want to declare it as a 
strong dependency (Depends:) of cassandra. I.e., if we don't consider it 
important enough that all users should have it, then we have either:

{noformat}
Package: cassandra
Recommends: cqlsh

Package: cqlsh
Depends: python-cql
{noformat}

or

{noformat}
Package: cassandra
Recommends: python-cql
{noformat}

And if it _is_ important enough, then we have either

{noformat}
Package: cassandra
Depends: cqlsh

Package: cqlsh
Depends: python-cql
{noformat}

or

{noformat}
Package: cassandra
Depends: python-cql
{noformat}

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Blocker
  Labels: cql, cqlsh
 Fix For: 1.0.7


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


Here is what might be a helpful thought experiment: _how would this have been 
solved, if cqlsh had been written in Java, using cassandra-jdbc?_ My estimation 
was, based on the past, that a cassandra-jdbc jar would probably just be 
bundled in with C* along with all the others. If that's true, the arguments 
against bundling cassandra-dbapi2 are not very convincing.

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Blocker
  Labels: cql, cqlsh
 Fix For: 1.0.7


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


bq. I don't think that's the case actually.

Oh, you're right. My mistake, sorry.

bq. Namely, if we do a change in cassandra that require a driver change 
(granted we don't want to do that too often but that has happen and will 
undoubtedly happen again), we have to wait on the driver to catch up to release.

This doesn't seem to follow to me. If we don't mind releasing a C* version for 
which the existing drivers don't work right, then it probably doesn't matter 
whether the drivers are available from the cassandra deb repo or not. And if we 
want to be sure the drivers are up-to-date for new C* features before we 
release a C* version, then we probably want that whether the drivers are 
available from the cassandra deb repo or not.

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Blocker
  Labels: cql, cqlsh
 Fix For: 1.0.7


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


bq. Maybe, but I've seen at least Jonathan and Eric state above that they 
wouldn't necessarily mind having cqlsh separate, and I've missed the part where 
they said ok, I'm convinced, it's worth having cqlsh in-tree.

The conversation about that, afaict, ended after a general agreement that if we 
remove cqlsh, we probably want to remove cassandra-cli as well, followed by an 
objection from Nick that Personally I think the user experience is 
significantly decreased if users have to download/build/install a separate 
project in order to actually interact with cassandra once it's running.

To sum up, my personal ideal solution would be to take cqlsh out of tree, along 
with cassandra-cli (and, actually, all the other bundled dependencies) and use 
package relationships to manage all that complexity (and just give tarball 
users a nice long installation readme).

But _if_ we want something built in to the main official C* tarball to allow 
talking to C* once it's running, I think we have to include cqlsh — based on 
the premise that the project wants cql to be the preferred mode of interface. 
If we include cassandra-cli but not cqlsh, cql will remain second-class. If we 
don't care about that, then yay, definitely we should leave cqlsh out.

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Blocker
  Labels: cql, cqlsh
 Fix For: 1.0.7


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


bq. Please be as careful with change to the debian packaging in stable release 
as you are with the rest of the code since it's part of the tree.

That's a little harsh- the debian package and the packaging aren't technically 
broken, they just require users to add a 3rd-party apt source or install a 
python-cql deb locally. But yeah, I doubt users really appreciate that 
distinction much.

bq. My preference goes to reverting CASSANDRA-3458, because I don't really like 
that we add something we're only mildly getting consensus on to a 1.0 release.

Do you mean we don't have strong consensus on including cqlsh in the official 
C* debs? Or that we don't have strong consensus on my proposal for a solution? 
I haven't seen any signs of disagreement in either case yet.

I'm +0 for just shipping a python-cql deb so that these problems get fixed, 
rather than putting them off, but I understand the need for stability.

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Blocker
  Labels: cql, cqlsh
 Fix For: 1.0.7


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3685) CQL support for non-utf8 column names

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3685:


I like the latter, if this is going to be syntax that is only supported in 
CREATE TABLE. Otherwise, it looks like a generic CQL function. (I know there's 
no technical ambiguity here, yet.)

 CQL support for non-utf8 column names
 -

 Key: CASSANDRA-3685
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3685
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Jonathan Ellis
  Labels: cql
 Fix For: 1.2


 Eric Evans' suggestions from the mailing list:
 {code}
 CREATE TABLE test (
   int(10) text,
   uuid(92d21d0a-d6cb-437c-9d3f-b67aa733a19f) bigint
 )
 {code}
 {code}
 CREATE TABLE test (
   (int)10 text,
   (uuid)92d21d0a-d6cb-437c-9d3f-b67aa733a19f bigint
 )
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


bq. Is it possible for the ASF contributors to vote on code that isn't in the 
official tree, like, say, a particular tag of the python CQL driver at Apache 
Extras? If we can distribute the drivers in the same official repository, most 
of these problems go away.

I read through all the rules I can find, and I see nothing prohibiting us from 
voting on and releasing specific source/binary artifacts of the various cql 
drivers alongside c*, as long as they follow the ASF licensing restrictions.

http://www.apache.org/dev/release.html#distribute-other-artifacts seems the 
most apropos.

So, I propose that we call a vote for a Cassandra project release of 
cassandra-dbapi2, alias python-cql, once I get the ASF licensing stuff sorted 
in it, and tag and post its 1.0.7 version. Then we can put the python-cql debs 
in the official debian repository, and everything is happy.

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cql, cqlsh
 Fix For: 1.1


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


All default Linux-based OS installs include Python nowadays, and so does Mac OS 
X. A py2exe compilation of cqlsh, along with a gui shell like IDLE, is a 
possibility for the Windows side. So no, there's no reason that switching to 
cqlsh should make the install or bootstrap processes more complicated.

Also, cqlsh is already written in python, and includes a lot of features which 
would probably be overly difficult or time-consuming to rewrite on the JVM.

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cql, cqlsh
 Fix For: 1.1


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3374) CQL can't create column with compression or that use leveled compaction

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3374:


+1

 CQL can't create column with compression or that use leveled compaction
 ---

 Key: CASSANDRA-3374
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3374
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0.0
Reporter: Sylvain Lebresne
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 1.0.7

 Attachments: CASSANDRA-3374.patch


 Looking at CreateColumnFamilyStatement.java, it doesn't seem CQL can create 
 compressed column families, nor define a compaction strategy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


Another solution proposed by eevans on irc:

bq. 14:01 urandom my personal opinion would be that cqlsh should be a 
different project (whether that means coupled with the driver, or stand-alone). 
 if that means that -cli is implicitly made more official when we'd rather it 
not be, then it should be removed
bq. 14:01 urandom but then, I know I'm in the minority in thinking that we 
don't need to be quite so batteries included on everything

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cql, cqlsh
 Fix For: 1.0.7


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


Is it possible for the ASF contributors to vote on code that isn't in the 
official tree, like, say, a particular tag of the python CQL driver at Apache 
Extras? If we can distribute the drivers in the same official repository, most 
of these problems go away.



If not, here are the alternatives as I see them:

1. Bundle python-cql with cqlsh deb, rpm, and tarball (whether cqlsh is in the 
same artifact with C* or not). This makes, by far, the most sense to me, since 
it's the same approach taken for nearly everything else in C*. I don't buy the 
everyone expects Java stuff to be bundled, and not Python stuff argument, 
because no one should be expecting any bundling, java or not, in actual OS 
packages. Also, the user shouldn't need to care what languages our tools are 
written in, so per-language expectations around bundling and packaging need not 
apply.

2. Add steps to the install instructions, or modify the instructions, so that 
users get C*/cqlsh/python-cql packages from a third party repo (like 
Datastax's).

3. Allow normal install of C* packages without any bundled python-cql, but have 
the cqlsh executable give instructions on how to download python-cql with the 
least amount of fuss for the local platform, when it is run.

4. Allow normal install of C* packages without any bundled python-cql, and have 
the cqlsh executable perform installation of python-cql automatically (giving 
the user a chance to cancel first). It could use a dot-directory under $HOME, 
and could be as simple as {{wget \-O - 
http://pypi.python.org/packages/source/c/cql/cql-$CQL_VERSION.tar.gz; | tar 
xz}} , so it wouldn't need administrator privileges.

5. (Don't even want to bring this up, but) Put python-cql back in the C* tree, 
so it can be voted on by the ASF people and put up in the same official C* 
repositories (and bundled, in the tarball case).

6. Get python-cql into the official OS repositories for all supported platforms 
(hint: probably not possible within the next, say, 3 years).

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cql, cqlsh
 Fix For: 1.1


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3101) Should check for errors when calling /bin/ln

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3101:


awesome.

+1

 Should check for errors when calling /bin/ln
 

 Key: CASSANDRA-3101
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3101
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.4
Reporter: paul cannon
Assignee: Vijay
Priority: Minor
  Labels: lhf
 Fix For: 1.0.6

 Attachments: 0001-0001-throw-IOE-while-calling-bin-ln-v2.patch, 
 0001-3101-throw-IOE-while-calling-bin-ln-v3.patch, 
 0001-3101-throw-IOE-while-calling-bin-ln.patch


 It looks like cassandra.utils.CLibrary.createHardLinkWithExec() does not 
 check for any errors in the execution of the hard-link-making utility. This 
 could be bad if, for example, the user has put the snapshot directory on a 
 different filesystem from the data directory. The hard linking would fail and 
 the sstable snapshots would not exist, but no error would be reported.
 It does look like errors with the more direct JNA link() call are handled 
 correctly- an exception is thrown. The WithExec version should probably do 
 the same thing.
 Definitely it would be enough to check the process exit value from /bin/ln 
 for nonzero in the *nix case, but I don't know whether 'fsutil hardlink 
 create' or 'cmd /c mklink /H' return nonzero on failure.
 For bonus points, use any output from the Process's error stream in the text 
 of the exception, to aid in debugging problems.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3477) cassandra takes too long to shut down when told to quit

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3477:


Joaquin- ready to close?

 cassandra takes too long to shut down when told to quit
 ---

 Key: CASSANDRA-3477
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3477
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Joaquin Casares
Assignee: paul cannon
Priority: Minor
 Fix For: 1.0.6


 The restart command keeps failing and never passes.
 The stop command seems to have completed successfully, but the processes is 
 still listed when I run 'ps auwx | grep cass'.
 Using the Debian6 images on Rackspace. 2 nodes are definitely showing the 
 same behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3101) Should check for errors when calling /bin/ln

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3101:


This works, except you've taken out a logger.error() call instead of adding 
another one. I think it's worth logging an error for the cassandra log in both 
cases.

 Should check for errors when calling /bin/ln
 

 Key: CASSANDRA-3101
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3101
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.4
Reporter: paul cannon
Assignee: Vijay
Priority: Minor
  Labels: lhf
 Fix For: 1.0.6

 Attachments: 0001-0001-throw-IOE-while-calling-bin-ln-v2.patch, 
 0001-3101-throw-IOE-while-calling-bin-ln.patch


 It looks like cassandra.utils.CLibrary.createHardLinkWithExec() does not 
 check for any errors in the execution of the hard-link-making utility. This 
 could be bad if, for example, the user has put the snapshot directory on a 
 different filesystem from the data directory. The hard linking would fail and 
 the sstable snapshots would not exist, but no error would be reported.
 It does look like errors with the more direct JNA link() call are handled 
 correctly- an exception is thrown. The WithExec version should probably do 
 the same thing.
 Definitely it would be enough to check the process exit value from /bin/ln 
 for nonzero in the *nix case, but I don't know whether 'fsutil hardlink 
 create' or 'cmd /c mklink /H' return nonzero on failure.
 For bonus points, use any output from the Process's error stream in the text 
 of the exception, to aid in debugging problems.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3101) Should check for errors when calling /bin/ln

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3101:


Vijay- I meant that the fsutil hardlink create command (which is already in 
the code) looks like the right one to use in all cases except Windows XP, but 
since we don't have a good way to verify, we might as well leave that part 
alone.

Let's just get rid of the unused imports and add the extra logger.error() call.

 Should check for errors when calling /bin/ln
 

 Key: CASSANDRA-3101
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3101
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.4
Reporter: paul cannon
Assignee: Vijay
Priority: Minor
  Labels: lhf
 Fix For: 1.0.6

 Attachments: 0001-3101-throw-IOE-while-calling-bin-ln.patch


 It looks like cassandra.utils.CLibrary.createHardLinkWithExec() does not 
 check for any errors in the execution of the hard-link-making utility. This 
 could be bad if, for example, the user has put the snapshot directory on a 
 different filesystem from the data directory. The hard linking would fail and 
 the sstable snapshots would not exist, but no error would be reported.
 It does look like errors with the more direct JNA link() call are handled 
 correctly- an exception is thrown. The WithExec version should probably do 
 the same thing.
 Definitely it would be enough to check the process exit value from /bin/ln 
 for nonzero in the *nix case, but I don't know whether 'fsutil hardlink 
 create' or 'cmd /c mklink /H' return nonzero on failure.
 For bonus points, use any output from the Process's error stream in the text 
 of the exception, to aid in debugging problems.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3476) Allow user to override jvm options picked by cassandra-env.sh

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3476:


+1

 Allow user to override jvm options picked by cassandra-env.sh
 -

 Key: CASSANDRA-3476
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3476
 Project: Cassandra
  Issue Type: Improvement
Reporter: Radim Kolar
Assignee: Radim Kolar
Priority: Minor
  Labels: lhf
 Fix For: 1.0.6

 Attachments: 3476.patch.txt, patch-env


 currently user have $JVM_OPTS - they are used before automagically generated 
 ops.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3337) Create a 'killtoken' command

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3337:


+1

 Create a 'killtoken' command
 

 Key: CASSANDRA-3337
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3337
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Brandon Williams
Assignee: Brandon Williams
  Labels: gossip
 Fix For: 1.0.6

 Attachments: 3337.txt


 Sometimes you just want a token gone: no re-replication, nothing, just excise 
 it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3485) Gossiper.addSavedEndpoint should never add itself

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3485:


+1.

 Gossiper.addSavedEndpoint should never add itself
 -

 Key: CASSANDRA-3485
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3485
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.7 beta 3
Reporter: Brandon Williams
Assignee: Brandon Williams
 Fix For: 0.8.9

 Attachments: 3485.txt


 Somehow, people are running into a situation where nodes are adding 
 themselves to the persisted ring cache.  Since SS is initialized after the 
 Gossiper and calls addSavedEndpoint on it, which inits the nodes with a 
 generation of zero, this ends up with nodes using a generation of zero and 
 thus never being marked as alive.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3101) Should check for errors when calling /bin/ln

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3101:


The following imports appear to be unused, and should probably be removed:

{code}
import java.io.BufferedInputStream;
import java.io.DataInputStream;
import java.io.InputStream;
import sun.misc.IOUtils;
{code}

Also, why add the logger.error() call in createHardLink, but not in 
createHardLinkWithExec? seems like if we want to know about the error in the C* 
log in the first case, we'd also want to know about it in the second case.

As a less important point, I wonder if it isn't worth modifying the existing 
hard-linking code a bit: cmd /c mklink /H seems a much more clunky way to 
make a hard link, and I think the logic is backwards: fsutil hardlink create 
is supported in all Windows versions since Windows Server 2000, except XP. 
Maybe the osversion comparison was meant to use cmd /c mklink /H in the 
Windows XP or less case, not Windows Vista or later.

Tested on Windows 7, though, after mounting a USB drive at the snapshots dir 
and trying to snapshot that keyspace. Error showed up correctly with output to 
nodetool, although no errors showed in the c* log.

 Should check for errors when calling /bin/ln
 

 Key: CASSANDRA-3101
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3101
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.4
Reporter: paul cannon
Assignee: Vijay
Priority: Minor
  Labels: lhf
 Fix For: 1.0.6

 Attachments: 0001-3101-throw-IOE-while-calling-bin-ln.patch


 It looks like cassandra.utils.CLibrary.createHardLinkWithExec() does not 
 check for any errors in the execution of the hard-link-making utility. This 
 could be bad if, for example, the user has put the snapshot directory on a 
 different filesystem from the data directory. The hard linking would fail and 
 the sstable snapshots would not exist, but no error would be reported.
 It does look like errors with the more direct JNA link() call are handled 
 correctly- an exception is thrown. The WithExec version should probably do 
 the same thing.
 Definitely it would be enough to check the process exit value from /bin/ln 
 for nonzero in the *nix case, but I don't know whether 'fsutil hardlink 
 create' or 'cmd /c mklink /H' return nonzero on failure.
 For bonus points, use any output from the Process's error stream in the text 
 of the exception, to aid in debugging problems.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3596) cqlsh: DESCRIBE output for a columnfamily does not work as input to same C* instance

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3596:


Yeah, actually, it looks like the fix is just to spell replicate_on_write 
correctly.

 cqlsh: DESCRIBE output for a columnfamily does not work as input to same C* 
 instance
 

 Key: CASSANDRA-3596
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3596
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.0.3
 Environment: Cqlsh running against a recent Cassandra build
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cqlsh
 Fix For: 1.0.6


 The {{DESCRIBE COLUMNFAMILY}} cqlsh command produces output that is intended 
 to be usable as valid CQL (at least, when given to another Cassandra instance 
 of the same version). But the output yields errors when run:
 {noformat}
 cqlsh USE blah;
 cqlsh:blah CREATE COLUMNFAMILY cf1 (c1 int PRIMARY KEY, c2 varchar);
 cqlsh:blah DESCRIBE COLUMNFAMILY cf1;
 CREATE COLUMNFAMILY cf1 (
   c1 int PRIMARY KEY,
   c2 text
 ) WITH
   comment='' AND
   comparator=text AND
   row_cache_provider='ConcurrentLinkedHashCacheProvider' AND
   key_cache_size=20.00 AND
   row_cache_size=0.00 AND
   read_repair_chance=0.10 AND
   gc_grace_seconds=864000 AND
   default_validation=text AND
   min_compaction_threshold=4 AND
   max_compaction_threshold=32 AND
   row_cache_save_period_in_seconds=0 AND
   key_cache_save_period_in_seconds=14400 AND
   replication_on_write=True;
 cqlsh:blah CREATE COLUMNFAMILY cf1 (
 ...   c1 int PRIMARY KEY,
 ...   c2 text
 ... ) WITH
 ...   comment='' AND
 ...   comparator=text AND
 ...   row_cache_provider='ConcurrentLinkedHashCacheProvider' AND
 ...   key_cache_size=20.00 AND
 ...   row_cache_size=0.00 AND
 ...   read_repair_chance=0.10 AND
 ...   gc_grace_seconds=864000 AND
 ...   default_validation=text AND
 ...   min_compaction_threshold=4 AND
 ...   max_compaction_threshold=32 AND
 ...   row_cache_save_period_in_seconds=0 AND
 ...   key_cache_save_period_in_seconds=14400 AND
 ...   replication_on_write=True;
 Bad Request: replication_on_write is not a valid keyword argument for CREATE 
 COLUMNFAMILY
 {noformat}
 So it needs to do a better job of determining which CF attributes are valid 
 for which C* versions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3419) CQL queries should allow CF names to be qualified by keyspace, part 2

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3419:


+1

 CQL queries should allow CF names to be qualified by keyspace, part 2
 -

 Key: CASSANDRA-3419
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3419
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: paul cannon
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 1.0.6

 Attachments: CASSANDRA-3419.patch


 See CASSANDRA-3130. The same treatment should be applied to the other related 
 CQL commands dealing with column family names, viz:
 * {{INSERT}}
 * {{UPDATE}}
 * {{DELETE}}
 * {{TRUNCATE}}
 Also, if the intent is to make it possible to go without {{USE}} entirely 
 (I'm not sure if it is):
 * {{CREATE COLUMNFAMILY}}
 * {{CREATE INDEX}}
 * {{DROP COLUMNFAMILY}}
 * {{ALTER COLUMNFAMILY}}
 * {{DROP INDEX}} (support {{keyspacename.indexname}}?)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3457) Make cqlsh look for a suitable python version

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3457:


bq. Why that particular ordering?

No strong reason. 2.6 is just a little more likely to be found than 2.7, over 
our expected set of install targets, and both 2.6 and 2.7 are little bits 
faster than 2.5.

Fine with changing to something else.

 Make cqlsh look for a suitable python version
 -

 Key: CASSANDRA-3457
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3457
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.0.3
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cqlsh
 Fix For: 1.0.5

 Attachments: 3457.patch.txt


 On RHEL 5, which I guess we still want to support, the default python in 
 the path is still 2.4. cqlsh does use a fair number of python features 
 introduced in 2.5, like collections.defaultdict, functools.partial, 
 generators. We can require RHEL 5 users to install a later python from EPEL, 
 but we'd have to call it as 'python2.5', or 'python2.6', etc.
 So rather than take the time to vet everything against python2.4, we may want 
 to make a wrapper script for cqlsh that checks for the existence of 
 python2.7, 2.6, and 2.5, and calls the appropriate one to run the real cqlsh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3457) Make cqlsh look for a suitable python version

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3457:


One minor edit: if we change the shebang from {{\#\!/bin/bash}} to 
{{\#\!/bin/sh}}, it will work for Solaris too. none of the code actually needs 
bash.

 Make cqlsh look for a suitable python version
 -

 Key: CASSANDRA-3457
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3457
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.0.3
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cqlsh
 Fix For: 1.0.5

 Attachments: 3457.patch.txt


 On RHEL 5, which I guess we still want to support, the default python in 
 the path is still 2.4. cqlsh does use a fair number of python features 
 introduced in 2.5, like collections.defaultdict, functools.partial, 
 generators. We can require RHEL 5 users to install a later python from EPEL, 
 but we'd have to call it as 'python2.5', or 'python2.6', etc.
 So rather than take the time to vet everything against python2.4, we may want 
 to make a wrapper script for cqlsh that checks for the existence of 
 python2.7, 2.6, and 2.5, and calls the appropriate one to run the real cqlsh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3507:


bq. Should we just spin cqlsh out to a separate project?

I expect that if cqlsh is in a different project, but cassandra-cli is 
distributed with c* proper, cassandra-cli will remain the de facto standard 
interactive interface, even if cqlsh is quite simple to install alongside. I've 
heard from several people that we want to transition to cqlsh over time, so 
that would make this an important issue.

But if we don't mind sticking with cassandra-cli (I don't really know), then it 
makes sense to split cqlsh into a different project.

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cql, cqlsh
 Fix For: 1.0.4


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2434) range movements can violate consistency

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-2434:


No, I do think that if we tore out the existing code and replaced it, it would 
be simpler overall, but (a) that would probably also be true if we rewrote the 
existing code without implementing this; (b) it will be rather a lot of work; 
and (c) it may engender a whole new generation of subtle corner-case bugs (or 
maybe it will eliminate a lot of such bugs that already exist).

 range movements can violate consistency
 ---

 Key: CASSANDRA-2434
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2434
 Project: Cassandra
  Issue Type: Bug
Reporter: Peter Schuller
Assignee: paul cannon
 Fix For: 1.0.4

 Attachments: 2434-3.patch.txt, 2434-testery.patch.txt


 My reading (a while ago) of the code indicates that there is no logic 
 involved during bootstrapping that avoids consistency level violations. If I 
 recall correctly it just grabs neighbors that are currently up.
 There are at least two issues I have with this behavior:
 * If I have a cluster where I have applications relying on QUORUM with RF=3, 
 and bootstrapping complete based on only one node, I have just violated the 
 supposedly guaranteed consistency semantics of the cluster.
 * Nodes can flap up and down at any time, so even if a human takes care to 
 look at which nodes are up and things about it carefully before 
 bootstrapping, there's no guarantee.
 A complication is that not only does it depend on use-case where this is an 
 issue (if all you ever do you do at CL.ONE, it's fine); even in a cluster 
 which is otherwise used for QUORUM operations you may wish to accept 
 less-than-quorum nodes during bootstrap in various emergency situations.
 A potential easy fix is to have bootstrap take an argument which is the 
 number of hosts to bootstrap from, or to assume QUORUM if none is given.
 (A related concern is bootstrapping across data centers. You may *want* to 
 bootstrap to a local node and then do a repair to avoid sending loads of data 
 across DC:s while still achieving consistency. Or even if you don't care 
 about the consistency issues, I don't think there is currently a way to 
 bootstrap from local nodes only.)
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2434) range movements can violate consistency

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-2434:


Do you mean to implement the new safe range movements procedure outlined 
above, without rewriting the rest of the range movement code?

If so, I submit a SWAG of 1/3-1/2 the cost of the rewrite option. The bandaid 
would still touch a lot of different moving parts.

 range movements can violate consistency
 ---

 Key: CASSANDRA-2434
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2434
 Project: Cassandra
  Issue Type: Bug
Reporter: Peter Schuller
Assignee: paul cannon
 Fix For: 1.0.4

 Attachments: 2434-3.patch.txt, 2434-testery.patch.txt


 My reading (a while ago) of the code indicates that there is no logic 
 involved during bootstrapping that avoids consistency level violations. If I 
 recall correctly it just grabs neighbors that are currently up.
 There are at least two issues I have with this behavior:
 * If I have a cluster where I have applications relying on QUORUM with RF=3, 
 and bootstrapping complete based on only one node, I have just violated the 
 supposedly guaranteed consistency semantics of the cluster.
 * Nodes can flap up and down at any time, so even if a human takes care to 
 look at which nodes are up and things about it carefully before 
 bootstrapping, there's no guarantee.
 A complication is that not only does it depend on use-case where this is an 
 issue (if all you ever do you do at CL.ONE, it's fine); even in a cluster 
 which is otherwise used for QUORUM operations you may wish to accept 
 less-than-quorum nodes during bootstrap in various emergency situations.
 A potential easy fix is to have bootstrap take an argument which is the 
 number of hosts to bootstrap from, or to assume QUORUM if none is given.
 (A related concern is bootstrapping across data centers. You may *want* to 
 bootstrap to a local node and then do a repair to avoid sending loads of data 
 across DC:s while still achieving consistency. Or even if you don't care 
 about the consistency issues, I don't think there is currently a way to 
 bootstrap from local nodes only.)
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3476) Allow user to override jvm options picked by cassandra-env.sh

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3476:


+1, although as a nitpick I'd prefer the variable be named {{JVM_EXTRA_OPTS}} 
instead of {{JVM_OVERRIDE_OPTS}}, since its value won't actually override the 
other {{JVM_OPTS}}.

 Allow user to override jvm options picked by cassandra-env.sh
 -

 Key: CASSANDRA-3476
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3476
 Project: Cassandra
  Issue Type: Improvement
Reporter: Radim Kolar
Assignee: Radim Kolar
Priority: Minor
  Labels: lhf
 Fix For: 1.0.4

 Attachments: patch-env


 currently user have $JVM_OPTS - they are used before automagically generated 
 ops.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3457) Make cqlsh look for a suitable python version

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3457:


Just a note for future reference- the opinion has been expressed that requiring 
EPEL for cassandra rpms may not be an option. Might need to remove the 2.5 
features from cqlsh and test it along with the python driver on 2.4.

 Make cqlsh look for a suitable python version
 -

 Key: CASSANDRA-3457
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3457
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor

 On RHEL 5, which I guess we still want to support, the default python in 
 the path is still 2.4. cqlsh does use a fair number of python features 
 introduced in 2.5, like collections.defaultdict, functools.partial, 
 generators. We can require RHEL 5 users to install a later python from EPEL, 
 but we'd have to call it as 'python2.5', or 'python2.6', etc.
 So rather than take the time to vet everything against python2.4, we may want 
 to make a wrapper script for cqlsh that checks for the existence of 
 python2.7, 2.6, and 2.5, and calls the appropriate one to run the real cqlsh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3418) Counter decrements require a space around the minus sign but not around the plus sign

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3418:


+1 for the fix

 Counter decrements require a space around the minus sign but not around the 
 plus sign
 -

 Key: CASSANDRA-3418
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3418
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 1.0.3

 Attachments: CASSANDRA-3418-fix.patch, CASSANDRA-3418.patch


 UPDATE validation_cf_counter SET test=test+1 WHERE id='test_key' = Success
 UPDATE validation_cf_counter SET test=test + 1 WHERE id='test_key' = Success
 UPDATE validation_cf_counter SET test=test - 1 WHERE id='test_key' = Success
 UPDATE validation_cf_counter SET test=test-1 WHERE id='test_key' = Failure 
 (line 1:38 no viable alternative at input 'test')

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3458) Add cqlsh to deb and rpm packaging

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3458:


I'm going to just punt on adding cqlsh to the rpm for now. The existing spec 
file is already way out of date and probably unworking, and it doesn't seem 
right to put in the work to fix it up under the rubric of this ticket. Can we 
just commit the addition to the deb for now?

 Add cqlsh to deb and rpm packaging
 --

 Key: CASSANDRA-3458
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3458
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
 Attachments: 3458.patch-debian.txt


 Once (if?) CASSANDRA-3188 is committed, cqlsh will be distributed with the 
 cassandra tarballs, but not in the debs or rpms. (Actually, it looks like the 
 cqlsh script will get put in the rpm by accident, but not its associated 
 libraries).
 We might even want to break cqlsh out into a separate package from the same 
 source, so that it can be installed on machines only intended to be used as 
 cassandra clients, not servers.
 Maybe that doesn't make sense without including nodetool and cassandra-cli 
 too, and then we'd need yet another package to hold the jars that are common 
 between cassandra and cassandra-client... maybe it's not worth it for now.
 Either way, make sure installing cassandra debs and rpms ends up with a 
 working cqlsh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2434) range movements can violate consistency

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-2434:


bq. It sounds like you have a reasonable solution here, is there any reason not 
to implement it for 1.1?

Just that it's quite a bit more complex than simply disallowing overlapping 
ring movements, and the extra problems that come with higher complexity. I 
think this feature is worth it, on its own, but when i think of how much pain 
Brandon seems to be going through dealing with streaming code, maybe it's not.

 range movements can violate consistency
 ---

 Key: CASSANDRA-2434
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2434
 Project: Cassandra
  Issue Type: Bug
Reporter: Peter Schuller
Assignee: paul cannon
 Fix For: 1.0.4

 Attachments: 2434-3.patch.txt, 2434-testery.patch.txt


 My reading (a while ago) of the code indicates that there is no logic 
 involved during bootstrapping that avoids consistency level violations. If I 
 recall correctly it just grabs neighbors that are currently up.
 There are at least two issues I have with this behavior:
 * If I have a cluster where I have applications relying on QUORUM with RF=3, 
 and bootstrapping complete based on only one node, I have just violated the 
 supposedly guaranteed consistency semantics of the cluster.
 * Nodes can flap up and down at any time, so even if a human takes care to 
 look at which nodes are up and things about it carefully before 
 bootstrapping, there's no guarantee.
 A complication is that not only does it depend on use-case where this is an 
 issue (if all you ever do you do at CL.ONE, it's fine); even in a cluster 
 which is otherwise used for QUORUM operations you may wish to accept 
 less-than-quorum nodes during bootstrap in various emergency situations.
 A potential easy fix is to have bootstrap take an argument which is the 
 number of hosts to bootstrap from, or to assume QUORUM if none is given.
 (A related concern is bootstrapping across data centers. You may *want* to 
 bootstrap to a local node and then do a repair to avoid sending loads of data 
 across DC:s while still achieving consistency. Or even if you don't care 
 about the consistency issues, I don't think there is currently a way to 
 bootstrap from local nodes only.)
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3418) Counter decrements require a space around the minus sign but not around the plus sign

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3418:


This doesn't do the right thing when minusing a negative value, like:

{noformat}
UPDATE validation_cf_counter SET test = test - -1 WHERE id='test_key';
{noformat}

It subtracts 1, instead of adding 1.

 Counter decrements require a space around the minus sign but not around the 
 plus sign
 -

 Key: CASSANDRA-3418
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3418
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 1.0.3

 Attachments: CASSANDRA-3418.patch


 UPDATE validation_cf_counter SET test=test+1 WHERE id='test_key' = Success
 UPDATE validation_cf_counter SET test=test + 1 WHERE id='test_key' = Success
 UPDATE validation_cf_counter SET test=test - 1 WHERE id='test_key' = Success
 UPDATE validation_cf_counter SET test=test-1 WHERE id='test_key' = Failure 
 (line 1:38 no viable alternative at input 'test')

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3477) sudo /etc/init.d/cassandra stop and restart don't work on Debian 6

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3477:


Joaquin- try running the initscript as {{sh -x /etc/init.d/cassandra stop}} (or 
{{restart}}) to see what it's doing. I expect in both cases it's just waiting 
for the cassandra process to stop, but that cassandra really is taking a long 
time to stop.

 sudo /etc/init.d/cassandra stop and restart don't work on Debian 6
 --

 Key: CASSANDRA-3477
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3477
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Reporter: Joaquin Casares
Assignee: paul cannon
Priority: Minor
 Fix For: 1.0.3


 The restart command keeps failing and never passes.
 The stop command seems to have completed successfully, but the processes is 
 still listed when I run 'ps auwx | grep cass'.
 Using the Debian6 images on Rackspace. 2 nodes are definitely showing the 
 same behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3477) sudo /etc/init.d/cassandra stop and restart don't work on Debian 6

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3477:


A return value of 2 from the initscript stop routine means that jsvc failed to 
stop the daemon.

(So the stop command seems to have completed successfully is inaccurate; a 
nonzero return value is the correct way for an initscript to indicate failure. 
If you want to see messages about progress/success/failure from initscripts, 
you should set {{VERBOSE=yes}} in {{/etc/default/rcS}}.)

At any rate, it looks like the bit to debug is jsvc. Can you try stopping the 
daemon with:

{noformat}
sudo /usr/bin/jsvc -stop -verbose -home /usr/lib/jvm/java-6-sun/jre/bin/../ \
-pidfile /var/run/cassandra.pid org.apache.cassandra.thrift.CassandraDaemon
{noformat}

..then see what exit code it gives, and see whether cassandra actually stops.

 sudo /etc/init.d/cassandra stop and restart don't work on Debian 6
 --

 Key: CASSANDRA-3477
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3477
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Reporter: Joaquin Casares
Assignee: paul cannon
Priority: Minor
 Fix For: 1.0.3


 The restart command keeps failing and never passes.
 The stop command seems to have completed successfully, but the processes is 
 still listed when I run 'ps auwx | grep cass'.
 Using the Debian6 images on Rackspace. 2 nodes are definitely showing the 
 same behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3477) sudo /etc/init.d/cassandra stop and restart don't work on Debian 6

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3477:


bq. Could we have it do that similar to the restart command?

Do what similar to the restart command? Do you mean print an error message? 
restart shouldn't be printing an error message either, unless {{VERBOSE=yes}}.

bq. This keeps going in a loop every time I execute.

Anything in the cassandra logs corresponding to the stop instruction?

 sudo /etc/init.d/cassandra stop and restart don't work on Debian 6
 --

 Key: CASSANDRA-3477
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3477
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Reporter: Joaquin Casares
Assignee: paul cannon
Priority: Minor
 Fix For: 1.0.3


 The restart command keeps failing and never passes.
 The stop command seems to have completed successfully, but the processes is 
 still listed when I run 'ps auwx | grep cass'.
 Using the Debian6 images on Rackspace. 2 nodes are definitely showing the 
 same behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3458) Add cqlsh to deb and rpm packaging

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3458:


So this is going to result in Cassandra depending on python-cql, which in turn 
depends on python-thrift, neither of which will be found in any official 
Debian/Ubuntu/RHEL/etc repositories. Most likely we'll need to put them in the 
ASF repository space at http://www.apache.org/dist/cassandra/ . The 
alternative, I guess, would be to bundle the python-cql and python-thrift 
libraries into the Cassandra packages at build time.

 Add cqlsh to deb and rpm packaging
 --

 Key: CASSANDRA-3458
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3458
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor

 Once (if?) CASSANDRA-3188 is committed, cqlsh will be distributed with the 
 cassandra tarballs, but not in the debs or rpms. (Actually, it looks like the 
 cqlsh script will get put in the rpm by accident, but not its associated 
 libraries).
 We might even want to break cqlsh out into a separate package from the same 
 source, so that it can be installed on machines only intended to be used as 
 cassandra clients, not servers.
 Maybe that doesn't make sense without including nodetool and cassandra-cli 
 too, and then we'd need yet another package to hold the jars that are common 
 between cassandra and cassandra-client... maybe it's not worth it for now.
 Either way, make sure installing cassandra debs and rpms ends up with a 
 working cqlsh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3131) cqlsh doesn't work on windows (no readline)

[paul cannon (Commented) (JIRA)]

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

paul cannon commented on CASSANDRA-3131:


Addressed in CASSANDRA-3188.

 cqlsh doesn't work on windows (no readline)
 ---

 Key: CASSANDRA-3131
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3131
 Project: Cassandra
  Issue Type: Bug
  Components: Drivers
Affects Versions: 0.8.4
Reporter: Eric Evans
Assignee: paul cannon
Priority: Minor
  Labels: cql

 Saulius Menkevicius reports in CASSANDRA-3010 that {{cqlsh}} doesn't start on 
 Windows because the readline module is not present.
 {{cqlsh}} should be fixed to only use readline if it is present.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira