[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 wrote: > +1 > On Sep 24, 2012 6:36 PM, "Gary Dusbabek" wrote: > >> +1 >> >> On Mon, Sep 24, 2012 at 4:52 PM, Sylvain Lebresne >> 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 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
TSocket read 0 bytes from cqlsh
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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 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 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 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
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 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 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 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 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 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=13436817&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13436817 On Thu, Oct 4, 2012 at 2:31 PM, Brian O'Neill 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 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 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 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 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 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=13436817&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13436817 > > On Thu, Oct 4, 2012 at 2:31 PM, Brian O'Neill 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 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 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 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 > 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
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 wrote:
> Perfect. Tnx.
>
> On Thu, Oct 4, 2012 at 3:37 PM, Jonathan Ellis 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=13436817&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13436817
>>
>> On Thu, Oct 4, 2012 at 2:31 PM, Brian O'Neill 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 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
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 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
>> 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
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 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 wrote:
>> Perfect. Tnx.
>>
>> On Thu, Oct 4, 2012 at 3:37 PM, Jonathan Ellis 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=13436817&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13436817
>>>
>>> On Thu, Oct 4, 2012 at 2:31 PM, Brian O'Neill 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 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
> 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 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
>>> 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 Cassa
