[VOTE SUCCESS] Release Apache Cassandra 1.0.12
I appears I've forgot about that vote :D So, counting 5 binding +1's, one other +1 and no -1's the vote passes. I'll get the artifacts published. On Tue, Sep 25, 2012 at 4:04 AM, Jason Brown jasedbr...@gmail.com wrote: +1 On Sep 24, 2012 6:36 PM, Gary Dusbabek gdusba...@gmail.com wrote: +1 On Mon, Sep 24, 2012 at 4:52 PM, Sylvain Lebresne sylv...@datastax.com wrote: We've just fixed CASSANDRA-4708 and have a few other minor fixes on the 1.0 branch since 1.0.11 so I propose the following artifacts for release as 1.0.12. sha1: 373e5b0d5104f17fca77edafbc033da99bced64c Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.12-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-035/org/apache/cassandra/apache-cassandra/1.0.12/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-035/ The artifacts as well as the debian package are also available here: http://people.apache.org/~slebresne/ The vote will be open for 72 hours (longer if needed). [1]: http://goo.gl/RRacv (CHANGES.txt) [2]: http://goo.gl/mJf2H (NEWS.txt)
Expected behavior of number of nodes contacted during CL=QUORUM read
Hi all, Test scenario: 4 nodes (.1, .2, .3, .4) RF=3 CL=QUORUM 1.1.2 I noticed that in ReadCallback's constructor, it determines the 'blockfor' number of 2 for RF=3, CL=QUORUM. According to the API page on the wiki[1] for reads at CL=QUORUM: Will query *all* replicas and return the record with the most recent timestamp once it has at least a majority of replicas (N / 2 + 1) reported. However, in ReadCallback's constructor, it determines blockfor to be 2, then calls filterEndpoints. filterEndpoints is given a list of the three replicas, but at the very end of the method, the endpoint list to only two replicas. Those two replicas are then used in StorageProxy to execute the read/digest calls. So it ends up as 2 nodes, not all three as stated on the wiki. In my test case, I kill a node and then immediately issue a query for a key that has a replica on the downed node. For the live nodes in the system, it doesn't immediately know that the other node is down yet. Rather than contacting *all* nodes as the wiki states, the coordinator contacts only two -- one of which is the downed node. Since it blocks for two, one of which is down, the query times out. Attempting the read again produces the same effect, even when trying different nodes as coordinators. I end up retrying a few times until the failure detectors on the live nodes realize that the node is down. So, the end result is that if a client attempts to read a row that has a replica on a newly downed node, it will timeout repeatedly until the ~30 seconds failure detector window has passed -- even though there are enough live replicas to satisfy the request. We basically have a scenario wherein a value is not retrievable for upwards of 30 seconds. The percentage of keys that exhibit this possibility shrinks as the ring grows, but it's still non-zero. This doesn't seem right and I'm sure I'm missing something. Thanks, Kirk [1] http://wiki.apache.org/cassandra/API
Re: Expected behavior of number of nodes contacted during CL=QUORUM read
On Thu, Oct 4, 2012 at 1:25 PM, Kirk True k...@mustardgrain.com wrote: Hi all, Test scenario: 4 nodes (.1, .2, .3, .4) RF=3 CL=QUORUM 1.1.2 I noticed that in ReadCallback's constructor, it determines the 'blockfor' number of 2 for RF=3, CL=QUORUM. Which is correct. floor(3/2) = 1, plus 1 equals 2. -Brandon
Re: Expected behavior of number of nodes contacted during CL=QUORUM read
The API page is incorrect. Cassandra only contacts enough nodes to satisfy the requested CL. https://issues.apache.org/jira/browse/CASSANDRA-4705 and https://issues.apache.org/jira/browse/CASSANDRA-2540 are relevant to the fragility that can result as you say. (Although, unless you are doing zero read repairs I would expect the dynamic snitch to steer requests away from the unresponsive node a lot faster than 30s.) On Thu, Oct 4, 2012 at 1:25 PM, Kirk True k...@mustardgrain.com wrote: Hi all, Test scenario: 4 nodes (.1, .2, .3, .4) RF=3 CL=QUORUM 1.1.2 I noticed that in ReadCallback's constructor, it determines the 'blockfor' number of 2 for RF=3, CL=QUORUM. According to the API page on the wiki[1] for reads at CL=QUORUM: Will query *all* replicas and return the record with the most recent timestamp once it has at least a majority of replicas (N / 2 + 1) reported. However, in ReadCallback's constructor, it determines blockfor to be 2, then calls filterEndpoints. filterEndpoints is given a list of the three replicas, but at the very end of the method, the endpoint list to only two replicas. Those two replicas are then used in StorageProxy to execute the read/digest calls. So it ends up as 2 nodes, not all three as stated on the wiki. In my test case, I kill a node and then immediately issue a query for a key that has a replica on the downed node. For the live nodes in the system, it doesn't immediately know that the other node is down yet. Rather than contacting *all* nodes as the wiki states, the coordinator contacts only two -- one of which is the downed node. Since it blocks for two, one of which is down, the query times out. Attempting the read again produces the same effect, even when trying different nodes as coordinators. I end up retrying a few times until the failure detectors on the live nodes realize that the node is down. So, the end result is that if a client attempts to read a row that has a replica on a newly downed node, it will timeout repeatedly until the ~30 seconds failure detector window has passed -- even though there are enough live replicas to satisfy the request. We basically have a scenario wherein a value is not retrievable for upwards of 30 seconds. The percentage of keys that exhibit this possibility shrinks as the ring grows, but it's still non-zero. This doesn't seem right and I'm sure I'm missing something. Thanks, Kirk [1] http://wiki.apache.org/cassandra/API -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: TSocket read 0 bytes from cqlsh
What kind of data did you insert, and what was expected? Expected behavior would be to reject nonconforming data at insert time. On Thu, Oct 4, 2012 at 2:04 PM, Brian O'Neill b...@alumni.brown.edu wrote: This is probably already on your radar, but we could use a better error message from cqlsh when the column key doesn't conform to the expected schema... I accidentally inserted data using Astyanax that didn't conform to the schema. After that, selects from that table via cqlsh return no useful information. (CLI shows the data just fine) bone@boneill-macbook-wired:~/tools/cassandra- bin/cassandra-cli Connected to: Test Cluster on 127.0.0.1/9160 Welcome to Cassandra CLI version 1.1.5 Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit. [default@unknown] use cirrus; Authenticated to keyspace: cirrus [default@cirrus] list data; Using default limit of 100 Using default column limit of 100 --- RowKey: PI7JC8 = (column=*, value=2014-07-31, timestamp=1349376866686000) --- RowKey: PI1234 = (column=*, value=Y, timestamp=1349372660453000) 2 Rows Returned. Elapsed time: 212 msec(s). [default@cirrus] quit; bone@boneill-macbook-wired:~/tools/cassandra- bin/cqlsh -3 Connected to Test Cluster at localhost:9160. [cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol 19.32.0] Use HELP for help. cqlsh use cirrus; cqlsh:cirrus select * from data; TSocket read 0 bytes cqlsh:cirrus -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: TSocket read 0 bytes from cqlsh
Obfuscated slightly The table is something simliar to: CREATE TABLE data ( uid varchar, t timestamp, foo varchar, bar varchar, PRIMARY KEY (uid, t, foo, bar) ); Then I can insert just fine via Astyanax and I can see the row via cli, but the select statement fails in cqlsh. The table is fine, when I only interact with it through CQL. I can insert and select fine, until I insert a row from Asytanax. If needed, I can probably create a small test for this that I can share. -brian On Thu, Oct 4, 2012 at 3:08 PM, Jonathan Ellis jbel...@gmail.com wrote: What kind of data did you insert, and what was expected? Expected behavior would be to reject nonconforming data at insert time. On Thu, Oct 4, 2012 at 2:04 PM, Brian O'Neill b...@alumni.brown.edu wrote: This is probably already on your radar, but we could use a better error message from cqlsh when the column key doesn't conform to the expected schema... I accidentally inserted data using Astyanax that didn't conform to the schema. After that, selects from that table via cqlsh return no useful information. (CLI shows the data just fine) bone@boneill-macbook-wired:~/tools/cassandra- bin/cassandra-cli Connected to: Test Cluster on 127.0.0.1/9160 Welcome to Cassandra CLI version 1.1.5 Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit. [default@unknown] use cirrus; Authenticated to keyspace: cirrus [default@cirrus] list data; Using default limit of 100 Using default column limit of 100 --- RowKey: PI7JC8 = (column=*, value=2014-07-31, timestamp=1349376866686000) --- RowKey: PI1234 = (column=*, value=Y, timestamp=1349372660453000) 2 Rows Returned. Elapsed time: 212 msec(s). [default@cirrus] quit; bone@boneill-macbook-wired:~/tools/cassandra- bin/cqlsh -3 Connected to Test Cluster at localhost:9160. [cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol 19.32.0] Use HELP for help. cqlsh use cirrus; cqlsh:cirrus select * from data; TSocket read 0 bytes cqlsh:cirrus -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42
Re: TSocket read 0 bytes from cqlsh
Here you go... ERROR 14:57:37,270 Error occurred during processing of message. java.lang.ArrayIndexOutOfBoundsException: 4 at org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:773) at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:137) at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108) at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121) at org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1237) at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542) at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530) 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:186) 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) On Thu, Oct 4, 2012 at 3:15 PM, Brian O'Neill b...@alumni.brown.edu wrote: Obfuscated slightly The table is something simliar to: CREATE TABLE data ( uid varchar, t timestamp, foo varchar, bar varchar, PRIMARY KEY (uid, t, foo, bar) ); Then I can insert just fine via Astyanax and I can see the row via cli, but the select statement fails in cqlsh. The table is fine, when I only interact with it through CQL. I can insert and select fine, until I insert a row from Asytanax. If needed, I can probably create a small test for this that I can share. -brian On Thu, Oct 4, 2012 at 3:08 PM, Jonathan Ellis jbel...@gmail.com wrote: What kind of data did you insert, and what was expected? Expected behavior would be to reject nonconforming data at insert time. On Thu, Oct 4, 2012 at 2:04 PM, Brian O'Neill b...@alumni.brown.edu wrote: This is probably already on your radar, but we could use a better error message from cqlsh when the column key doesn't conform to the expected schema... I accidentally inserted data using Astyanax that didn't conform to the schema. After that, selects from that table via cqlsh return no useful information. (CLI shows the data just fine) bone@boneill-macbook-wired:~/tools/cassandra- bin/cassandra-cli Connected to: Test Cluster on 127.0.0.1/9160 Welcome to Cassandra CLI version 1.1.5 Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit. [default@unknown] use cirrus; Authenticated to keyspace: cirrus [default@cirrus] list data; Using default limit of 100 Using default column limit of 100 --- RowKey: PI7JC8 = (column=*, value=2014-07-31, timestamp=1349376866686000) --- RowKey: PI1234 = (column=*, value=Y, timestamp=1349372660453000) 2 Rows Returned. Elapsed time: 212 msec(s). [default@cirrus] quit; bone@boneill-macbook-wired:~/tools/cassandra- bin/cqlsh -3 Connected to Test Cluster at localhost:9160. [cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol 19.32.0] Use HELP for help. cqlsh use cirrus; cqlsh:cirrus select * from data; TSocket read 0 bytes cqlsh:cirrus -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42
Re: TSocket read 0 bytes from cqlsh
From this, I assume I inserted the wrong number of values into the compound key from Astyanax. It would be nice to carry this error across to the CQL client. -brian On Thu, Oct 4, 2012 at 3:17 PM, Brian O'Neill b...@alumni.brown.edu wrote: Here you go... ERROR 14:57:37,270 Error occurred during processing of message. java.lang.ArrayIndexOutOfBoundsException: 4 at org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:773) at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:137) at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108) at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121) at org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1237) at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542) at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530) 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:186) 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) On Thu, Oct 4, 2012 at 3:15 PM, Brian O'Neill b...@alumni.brown.edu wrote: Obfuscated slightly The table is something simliar to: CREATE TABLE data ( uid varchar, t timestamp, foo varchar, bar varchar, PRIMARY KEY (uid, t, foo, bar) ); Then I can insert just fine via Astyanax and I can see the row via cli, but the select statement fails in cqlsh. The table is fine, when I only interact with it through CQL. I can insert and select fine, until I insert a row from Asytanax. If needed, I can probably create a small test for this that I can share. -brian On Thu, Oct 4, 2012 at 3:08 PM, Jonathan Ellis jbel...@gmail.com wrote: What kind of data did you insert, and what was expected? Expected behavior would be to reject nonconforming data at insert time. On Thu, Oct 4, 2012 at 2:04 PM, Brian O'Neill b...@alumni.brown.edu wrote: This is probably already on your radar, but we could use a better error message from cqlsh when the column key doesn't conform to the expected schema... I accidentally inserted data using Astyanax that didn't conform to the schema. After that, selects from that table via cqlsh return no useful information. (CLI shows the data just fine) bone@boneill-macbook-wired:~/tools/cassandra- bin/cassandra-cli Connected to: Test Cluster on 127.0.0.1/9160 Welcome to Cassandra CLI version 1.1.5 Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit. [default@unknown] use cirrus; Authenticated to keyspace: cirrus [default@cirrus] list data; Using default limit of 100 Using default column limit of 100 --- RowKey: PI7JC8 = (column=*, value=2014-07-31, timestamp=1349376866686000) --- RowKey: PI1234 = (column=*, value=Y, timestamp=1349372660453000) 2 Rows Returned. Elapsed time: 212 msec(s). [default@cirrus] quit; bone@boneill-macbook-wired:~/tools/cassandra- bin/cqlsh -3 Connected to Test Cluster at localhost:9160. [cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol 19.32.0] Use HELP for help. cqlsh use cirrus; cqlsh:cirrus select * from data; TSocket read 0 bytes cqlsh:cirrus -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42
Re: TSocket read 0 bytes from cqlsh
Nothing jumps out at me, varchar should be pretty straightforward. Probably going to need a test case. (Even better if you can repro w/ cli instead of needing Astyanax.) On Thu, Oct 4, 2012 at 2:15 PM, Brian O'Neill b...@alumni.brown.edu wrote: Obfuscated slightly The table is something simliar to: CREATE TABLE data ( uid varchar, t timestamp, foo varchar, bar varchar, PRIMARY KEY (uid, t, foo, bar) ); Then I can insert just fine via Astyanax and I can see the row via cli, but the select statement fails in cqlsh. The table is fine, when I only interact with it through CQL. I can insert and select fine, until I insert a row from Asytanax. If needed, I can probably create a small test for this that I can share. -brian On Thu, Oct 4, 2012 at 3:08 PM, Jonathan Ellis jbel...@gmail.com wrote: What kind of data did you insert, and what was expected? Expected behavior would be to reject nonconforming data at insert time. On Thu, Oct 4, 2012 at 2:04 PM, Brian O'Neill b...@alumni.brown.edu wrote: This is probably already on your radar, but we could use a better error message from cqlsh when the column key doesn't conform to the expected schema... I accidentally inserted data using Astyanax that didn't conform to the schema. After that, selects from that table via cqlsh return no useful information. (CLI shows the data just fine) bone@boneill-macbook-wired:~/tools/cassandra- bin/cassandra-cli Connected to: Test Cluster on 127.0.0.1/9160 Welcome to Cassandra CLI version 1.1.5 Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit. [default@unknown] use cirrus; Authenticated to keyspace: cirrus [default@cirrus] list data; Using default limit of 100 Using default column limit of 100 --- RowKey: PI7JC8 = (column=*, value=2014-07-31, timestamp=1349376866686000) --- RowKey: PI1234 = (column=*, value=Y, timestamp=1349372660453000) 2 Rows Returned. Elapsed time: 212 msec(s). [default@cirrus] quit; bone@boneill-macbook-wired:~/tools/cassandra- bin/cqlsh -3 Connected to Test Cluster at localhost:9160. [cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol 19.32.0] Use HELP for help. cqlsh use cirrus; cqlsh:cirrus select * from data; TSocket read 0 bytes cqlsh:cirrus -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: TSocket read 0 bytes from cqlsh
Here you go... // // IN CQLSH // CREATE KEYSPACE cirrus WITH strategy_class = 'NetworkTopologyStrategy' AND strategy_options:datacenter1 = '1'; use cirrus; CREATE TABLE data ( uid varchar, t timestamp, foo varchar, bar varchar, PRIMARY KEY (uid, t, foo) ); // // Then in CLI // use cirrus; set data['PI7JC8KRF6']['1349110576']='2014-07-31'; list data; // Note, I intentially didn't supply a value for foo in the primary key definition. // Listing works. // // Then in CLI // select * from data; // The result is... cqlsh:cirrus select * from data; TSocket read 0 bytes On Thu, Oct 4, 2012 at 3:31 PM, Brian O'Neill b...@alumni.brown.edu wrote: I was able to reproduce with CLI. I'll send over the example as soon as I can obfuscate it. -brian On Thu, Oct 4, 2012 at 3:19 PM, Jonathan Ellis jbel...@gmail.com wrote: Nothing jumps out at me, varchar should be pretty straightforward. Probably going to need a test case. (Even better if you can repro w/ cli instead of needing Astyanax.) On Thu, Oct 4, 2012 at 2:15 PM, Brian O'Neill b...@alumni.brown.edu wrote: Obfuscated slightly The table is something simliar to: CREATE TABLE data ( uid varchar, t timestamp, foo varchar, bar varchar, PRIMARY KEY (uid, t, foo, bar) ); Then I can insert just fine via Astyanax and I can see the row via cli, but the select statement fails in cqlsh. The table is fine, when I only interact with it through CQL. I can insert and select fine, until I insert a row from Asytanax. If needed, I can probably create a small test for this that I can share. -brian On Thu, Oct 4, 2012 at 3:08 PM, Jonathan Ellis jbel...@gmail.com wrote: What kind of data did you insert, and what was expected? Expected behavior would be to reject nonconforming data at insert time. On Thu, Oct 4, 2012 at 2:04 PM, Brian O'Neill b...@alumni.brown.edu wrote: This is probably already on your radar, but we could use a better error message from cqlsh when the column key doesn't conform to the expected schema... I accidentally inserted data using Astyanax that didn't conform to the schema. After that, selects from that table via cqlsh return no useful information. (CLI shows the data just fine) bone@boneill-macbook-wired:~/tools/cassandra- bin/cassandra-cli Connected to: Test Cluster on 127.0.0.1/9160 Welcome to Cassandra CLI version 1.1.5 Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit. [default@unknown] use cirrus; Authenticated to keyspace: cirrus [default@cirrus] list data; Using default limit of 100 Using default column limit of 100 --- RowKey: PI7JC8 = (column=*, value=2014-07-31, timestamp=1349376866686000) --- RowKey: PI1234 = (column=*, value=Y, timestamp=1349372660453000) 2 Rows Returned. Elapsed time: 212 msec(s). [default@cirrus] quit; bone@boneill-macbook-wired:~/tools/cassandra- bin/cqlsh -3 Connected to Test Cluster at localhost:9160. [cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol 19.32.0] Use HELP for help. cqlsh use cirrus; cqlsh:cirrus select * from data; TSocket read 0 bytes cqlsh:cirrus -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42
Re: TSocket read 0 bytes from cqlsh
Oh, I see. I misunderstood at first. Yes, the thrift side in 1.1 doesn't validate cql3 composites. This should be fixed in 1.2 beta1; see https://issues.apache.org/jira/browse/CASSANDRA-4377?focusedCommentId=13436817page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13436817 On Thu, Oct 4, 2012 at 2:31 PM, Brian O'Neill b...@alumni.brown.edu wrote: I was able to reproduce with CLI. I'll send over the example as soon as I can obfuscate it. -brian On Thu, Oct 4, 2012 at 3:19 PM, Jonathan Ellis jbel...@gmail.com wrote: Nothing jumps out at me, varchar should be pretty straightforward. Probably going to need a test case. (Even better if you can repro w/ cli instead of needing Astyanax.) On Thu, Oct 4, 2012 at 2:15 PM, Brian O'Neill b...@alumni.brown.edu wrote: Obfuscated slightly The table is something simliar to: CREATE TABLE data ( uid varchar, t timestamp, foo varchar, bar varchar, PRIMARY KEY (uid, t, foo, bar) ); Then I can insert just fine via Astyanax and I can see the row via cli, but the select statement fails in cqlsh. The table is fine, when I only interact with it through CQL. I can insert and select fine, until I insert a row from Asytanax. If needed, I can probably create a small test for this that I can share. -brian On Thu, Oct 4, 2012 at 3:08 PM, Jonathan Ellis jbel...@gmail.com wrote: What kind of data did you insert, and what was expected? Expected behavior would be to reject nonconforming data at insert time. On Thu, Oct 4, 2012 at 2:04 PM, Brian O'Neill b...@alumni.brown.edu wrote: This is probably already on your radar, but we could use a better error message from cqlsh when the column key doesn't conform to the expected schema... I accidentally inserted data using Astyanax that didn't conform to the schema. After that, selects from that table via cqlsh return no useful information. (CLI shows the data just fine) bone@boneill-macbook-wired:~/tools/cassandra- bin/cassandra-cli Connected to: Test Cluster on 127.0.0.1/9160 Welcome to Cassandra CLI version 1.1.5 Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit. [default@unknown] use cirrus; Authenticated to keyspace: cirrus [default@cirrus] list data; Using default limit of 100 Using default column limit of 100 --- RowKey: PI7JC8 = (column=*, value=2014-07-31, timestamp=1349376866686000) --- RowKey: PI1234 = (column=*, value=Y, timestamp=1349372660453000) 2 Rows Returned. Elapsed time: 212 msec(s). [default@cirrus] quit; bone@boneill-macbook-wired:~/tools/cassandra- bin/cqlsh -3 Connected to Test Cluster at localhost:9160. [cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol 19.32.0] Use HELP for help. cqlsh use cirrus; cqlsh:cirrus select * from data; TSocket read 0 bytes cqlsh:cirrus -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: TSocket read 0 bytes from cqlsh
Perfect. Tnx. On Thu, Oct 4, 2012 at 3:37 PM, Jonathan Ellis jbel...@gmail.com wrote: Oh, I see. I misunderstood at first. Yes, the thrift side in 1.1 doesn't validate cql3 composites. This should be fixed in 1.2 beta1; see https://issues.apache.org/jira/browse/CASSANDRA-4377?focusedCommentId=13436817page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13436817 On Thu, Oct 4, 2012 at 2:31 PM, Brian O'Neill b...@alumni.brown.edu wrote: I was able to reproduce with CLI. I'll send over the example as soon as I can obfuscate it. -brian On Thu, Oct 4, 2012 at 3:19 PM, Jonathan Ellis jbel...@gmail.com wrote: Nothing jumps out at me, varchar should be pretty straightforward. Probably going to need a test case. (Even better if you can repro w/ cli instead of needing Astyanax.) On Thu, Oct 4, 2012 at 2:15 PM, Brian O'Neill b...@alumni.brown.edu wrote: Obfuscated slightly The table is something simliar to: CREATE TABLE data ( uid varchar, t timestamp, foo varchar, bar varchar, PRIMARY KEY (uid, t, foo, bar) ); Then I can insert just fine via Astyanax and I can see the row via cli, but the select statement fails in cqlsh. The table is fine, when I only interact with it through CQL. I can insert and select fine, until I insert a row from Asytanax. If needed, I can probably create a small test for this that I can share. -brian On Thu, Oct 4, 2012 at 3:08 PM, Jonathan Ellis jbel...@gmail.com wrote: What kind of data did you insert, and what was expected? Expected behavior would be to reject nonconforming data at insert time. On Thu, Oct 4, 2012 at 2:04 PM, Brian O'Neill b...@alumni.brown.edu wrote: This is probably already on your radar, but we could use a better error message from cqlsh when the column key doesn't conform to the expected schema... I accidentally inserted data using Astyanax that didn't conform to the schema. After that, selects from that table via cqlsh return no useful information. (CLI shows the data just fine) bone@boneill-macbook-wired:~/tools/cassandra- bin/cassandra-cli Connected to: Test Cluster on 127.0.0.1/9160 Welcome to Cassandra CLI version 1.1.5 Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit. [default@unknown] use cirrus; Authenticated to keyspace: cirrus [default@cirrus] list data; Using default limit of 100 Using default column limit of 100 --- RowKey: PI7JC8 = (column=*, value=2014-07-31, timestamp=1349376866686000) --- RowKey: PI1234 = (column=*, value=Y, timestamp=1349372660453000) 2 Rows Returned. Elapsed time: 212 msec(s). [default@cirrus] quit; bone@boneill-macbook-wired:~/tools/cassandra- bin/cqlsh -3 Connected to Test Cluster at localhost:9160. [cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol 19.32.0] Use HELP for help. cqlsh use cirrus; cqlsh:cirrus select * from data; TSocket read 0 bytes cqlsh:cirrus -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42
Re: TSocket read 0 bytes from cqlsh
Scratch that it can change on a per column basis.
Strange world this Java API vs. CQL.
-brian
On Thu, Oct 4, 2012 at 3:57 PM, Brian O'Neill b...@alumni.brown.edu wrote:
Actually, I found the underlying issue...
CQL appends the *name* of the value column into the compound key.
Using the previous schema:
insert into data (uid, t, foo, bar) values ('PI7JC8KRF6',
'1349110576', 'foovalue', 'barvalue')
list data;
RowKey: PI7JC8KRF6
= (column=1970-01-16 09:45:10-0500:foovalue:bar, value=barvalue,
timestamp=1349380029082000)
Notice bar is on the end of the column name.
If you don't have that element represented from the Java API (in this
case, w/ Astyanax), you end up with misaligned interpretation of the
compound key. I'll add an extra element to the composite type in
Astyanax, which should fix things. I'll also add this to my blog so
other people don't get tripped up.
Any insight into why CQL puts that in column name?
Where does it store the metadata related to compound key
interpretation? Wouldn't that be a better place for that since it
shouldn't change within a table?
-brian
On Thu, Oct 4, 2012 at 3:39 PM, Brian O'Neill b...@alumni.brown.edu wrote:
Perfect. Tnx.
On Thu, Oct 4, 2012 at 3:37 PM, Jonathan Ellis jbel...@gmail.com wrote:
Oh, I see. I misunderstood at first. Yes, the thrift side in 1.1
doesn't validate cql3 composites. This should be fixed in 1.2 beta1;
see
https://issues.apache.org/jira/browse/CASSANDRA-4377?focusedCommentId=13436817page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13436817
On Thu, Oct 4, 2012 at 2:31 PM, Brian O'Neill b...@alumni.brown.edu wrote:
I was able to reproduce with CLI. I'll send over the example as soon
as I can obfuscate it.
-brian
On Thu, Oct 4, 2012 at 3:19 PM, Jonathan Ellis jbel...@gmail.com wrote:
Nothing jumps out at me, varchar should be pretty straightforward.
Probably going to need a test case. (Even better if you can repro w/
cli instead of needing Astyanax.)
On Thu, Oct 4, 2012 at 2:15 PM, Brian O'Neill b...@alumni.brown.edu
wrote:
Obfuscated slightly
The table is something simliar to:
CREATE TABLE data (
uid varchar,
t timestamp,
foo varchar,
bar varchar,
PRIMARY KEY (uid, t, foo, bar)
);
Then I can insert just fine via Astyanax and I can see the row via
cli, but the select statement fails in cqlsh.
The table is fine, when I only interact with it through CQL. I can
insert and select fine, until I insert a row from Asytanax.
If needed, I can probably create a small test for this that I can share.
-brian
On Thu, Oct 4, 2012 at 3:08 PM, Jonathan Ellis jbel...@gmail.com wrote:
What kind of data did you insert, and what was expected? Expected
behavior would be to reject nonconforming data at insert time.
On Thu, Oct 4, 2012 at 2:04 PM, Brian O'Neill b...@alumni.brown.edu
wrote:
This is probably already on your radar, but we could use a better
error message from cqlsh when the column key doesn't conform to the
expected schema...
I accidentally inserted data using Astyanax that didn't conform to the
schema. After that, selects from that table via cqlsh return no
useful information.
(CLI shows the data just fine)
bone@boneill-macbook-wired:~/tools/cassandra- bin/cassandra-cli
Connected to: Test Cluster on 127.0.0.1/9160
Welcome to Cassandra CLI version 1.1.5
Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.
[default@unknown] use cirrus;
Authenticated to keyspace: cirrus
[default@cirrus] list data;
Using default limit of 100
Using default column limit of 100
---
RowKey: PI7JC8
= (column=*, value=2014-07-31, timestamp=1349376866686000)
---
RowKey: PI1234
= (column=*, value=Y, timestamp=1349372660453000)
2 Rows Returned.
Elapsed time: 212 msec(s).
[default@cirrus] quit;
bone@boneill-macbook-wired:~/tools/cassandra- bin/cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol
19.32.0]
Use HELP for help.
cqlsh use cirrus;
cqlsh:cirrus select * from data;
TSocket read 0 bytes
cqlsh:cirrus
--
Brian ONeill
Lead Architect, Health Market Science (http://healthmarketscience.com)
mobile:215.588.6024
blog: http://brianoneill.blogspot.com/
twitter: @boneill42
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
--
Brian ONeill
Lead Architect, Health Market Science (http://healthmarketscience.com)
mobile:215.588.6024
blog: http://brianoneill.blogspot.com/
twitter: @boneill42
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
--
Brian ONeill
Lead Architect, Health Market Science (http://healthmarketscience.com)
mobile:215.588.6024
blog:
