[jira] [Commented] (CASSANDRA-11299) AssertionError when quering by secondary index
[ https://issues.apache.org/jira/browse/CASSANDRA-11299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179530#comment-15179530 ] Michał Matłoka commented on CASSANDRA-11299: {code} CREATE TABLE mykeyspace.mytable ( id text PRIMARY KEY, attributes map, someflag boolean, sometimestamp1 timestamp, sometimestamp2 timestamp, sometimestamp3 timestamp, sometimestamp4 timestamp, sometimestamp5 timestamp, someotherflag boolean, systemotherattributes map ) WITH bloom_filter_fp_chance = 0.01 AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND comment = '' AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'} AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'} AND crc_check_chance = 1.0 AND dclocal_read_repair_chance = 0.1 AND default_time_to_live = 0 AND gc_grace_seconds = 864000 AND max_index_interval = 2048 AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128 AND read_repair_chance = 0.0 AND speculative_retry = '99PERCENTILE'; CREATE INDEX mytable_sometimestamp1_idx ON mykeyspace.mytable (sometimestamp1); CREATE INDEX mytable_someflag_idx ON mykeyspace.mytable (someflag); CREATE INDEX mytable_systemotherattributes_idx ON mykeyspace.mytable (keys(systemotherattributes)); {code} so using those column names the problematic queries were e.g.: {code} select * from table where someflag = true; {code} {code} select * from table where systemotherattributes contains key 'Sth'; {code} {code} select * from table where someflag = true and sometimestamp1 > '2016'; {code} > AssertionError when quering by secondary index > -- > > Key: CASSANDRA-11299 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11299 > Project: Cassandra > Issue Type: Bug > Environment: Cassandra 3.3 >Reporter: Michał Matłoka > > Hi, > Recently we have upgraded from Cassandra 2.2.4 to 3.3. I have issues with one > table. When I try to query using any secondary index I get e.g. in cqlsh > {code} > Traceback (most recent call last): > File "/usr/bin/cqlsh.py", line 1249, in perform_simple_statement > result = future.result() > File > "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py", > line 3122, in result > raise self._final_exception > ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation > failed - received 0 responses and 1 failures" info={'failures': 1, > 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'} > {code} > Node logs shows then: > {code} > [[AWARN [SharedPool-Worker-2] 2016-03-03 00:47:01,679 > AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread > Thread[SharedPool-Worker-2,5,main]: {} > java.lang.AssertionError: null > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:225) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:215) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:133) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:89) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:294) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:134) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:127) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:292) > ~[apache-cassandra-3.3.0.jar:3.3.0] > a
[jira] [Commented] (CASSANDRA-11299) AssertionError when quering by secondary index
[ https://issues.apache.org/jira/browse/CASSANDRA-11299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179535#comment-15179535 ] Michał Matłoka commented on CASSANDRA-11299: And I had at a same time case where {code} select * from table where id = 'sth'; {code} returned 2 rows, with different subsets of columns (like second row would be comming from a specific update query) This was ultra strange, especially because any repair didn't handle that. > AssertionError when quering by secondary index > -- > > Key: CASSANDRA-11299 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11299 > Project: Cassandra > Issue Type: Bug > Environment: Cassandra 3.3 >Reporter: Michał Matłoka > > Hi, > Recently we have upgraded from Cassandra 2.2.4 to 3.3. I have issues with one > table. When I try to query using any secondary index I get e.g. in cqlsh > {code} > Traceback (most recent call last): > File "/usr/bin/cqlsh.py", line 1249, in perform_simple_statement > result = future.result() > File > "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py", > line 3122, in result > raise self._final_exception > ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation > failed - received 0 responses and 1 failures" info={'failures': 1, > 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'} > {code} > Node logs shows then: > {code} > [[AWARN [SharedPool-Worker-2] 2016-03-03 00:47:01,679 > AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread > Thread[SharedPool-Worker-2,5,main]: {} > java.lang.AssertionError: null > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:225) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:215) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:133) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:89) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:294) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:134) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:127) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:292) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1789) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2457) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > ~[na:1.8.0_66] > at > org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164) > ~[apache-cassandra-3.3.0.jar:3.3.0] > at > org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136) > [apache-cassandra-3.3.0.jar:3.3.0] > at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) > [apache-cassandra-3.3.0.jar:3.3.0] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66] > {code} > SStables are upgraded, I have tried repair and scrub. I have tried to rebuild > indexes, and even remove them and re-add them.It occurs on every cluster node. > Additionally I had seen in this table case where PRIMARY KEY was > duplicated!!! (there were two rows with same primary key, by seeing what > columns were set I can s
[jira] [Commented] (CASSANDRA-6377) ALLOW FILTERING should allow seq scan filtering
[ https://issues.apache.org/jira/browse/CASSANDRA-6377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179650#comment-15179650 ] Sam Tunnicliffe commented on CASSANDRA-6377: +1 on the patches, +0 on changing the ticket type. A quick grep shows there are quite a few places in tests (on all 3 branches) where we should use {{StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE}}, I know it's very nit-picky, but it would be good to fix those on commit. > ALLOW FILTERING should allow seq scan filtering > --- > > Key: CASSANDRA-6377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6377 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Jonathan Ellis >Assignee: Benjamin Lerer > Labels: cql > Fix For: 3.0.x, 3.x > > > CREATE TABLE emp_table2 ( > empID int PRIMARY KEY, > firstname text, > lastname text, > b_mon text, > b_day text, > b_yr text, > ); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (100,'jane','doe','oct','31','1980'); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (101,'john','smith','jan','01','1981'); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (102,'mary','jones','apr','15','1982'); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (103,'tim','best','oct','25','1982'); > > SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2 > WHERE b_mon='oct' ALLOW FILTERING; > Bad Request: No indexed columns present in by-columns clause with Equal > operator -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10707) Add support for Group By to Select statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179733#comment-15179733 ] Benjamin Lerer commented on CASSANDRA-10707: {quote}I noticed that CQLLimits.forShortReadRetry() does not provide any limit on the number of rows either.{quote} It looks like I was really tired when I looked at the code :-( {quote}Not sure about CQLGroupByLimits.forShortReadRetry(). I believe putting no limit on the number of rows (and only on the group) might lead to OOM. In fact, I need to think more carefully about this but I'm not 100% sure that the short read logic isn't throw off by the fact that counted() returns a number of groups not rows.{quote} I think my implementation for {{forShortReadRetry()}} is simply wrong. The goal of the short read retry is to fetch the rows that were missing for a given partition due to short read. As the number of rows to request is computed in {{ShortReadRowProtection:: moreContents}} I believe that even in the case of {{GROUP BY}} we should use a {{CQLLimits}} to request the rows. > Add support for Group By to Select statement > > > Key: CASSANDRA-10707 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10707 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer > > Now that Cassandra support aggregate functions, it makes sense to support > {{GROUP BY}} on the {{SELECT}} statements. > It should be possible to group either at the partition level or at the > clustering column level. > {code} > SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey; > SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP > BY partitionKey, clustering0, clustering1; > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10707) Add support for Group By to Select statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179738#comment-15179738 ] Benjamin Lerer commented on CASSANDRA-10707: I missed the problem of the counted. Yes, I agree with your statement the short read logic will probably not work for group by. I will look deeper in it. > Add support for Group By to Select statement > > > Key: CASSANDRA-10707 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10707 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer > > Now that Cassandra support aggregate functions, it makes sense to support > {{GROUP BY}} on the {{SELECT}} statements. > It should be possible to group either at the partition level or at the > clustering column level. > {code} > SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey; > SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP > BY partitionKey, clustering0, clustering1; > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11304) Query data through a secondary index
Job Tiel Groenestege created CASSANDRA-11304: Summary: Query data through a secondary index Key: CASSANDRA-11304 URL: https://issues.apache.org/jira/browse/CASSANDRA-11304 Project: Cassandra Issue Type: Bug Components: Core, CQL Environment: 3 Node cluster / Ubuntu 14.04 / Cassandra 3.0.3 Reporter: Job Tiel Groenestege When reading data through a secondary index _select * from tableName where secIndexField = 'foo'_ (from a Java application) I get the following stacktrace on all nodes; after the query read fails. It happens repeatably when I rerun the same query: {quote} WARN [SharedPool-Worker-8] 2016-03-04 13:26:28,041 AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread Thread[SharedPool-Worker-8,5,main]: {} java.lang.StackOverflowError: null at org.apache.cassandra.db.rows.BTreeRow$Builder.build(BTreeRow.java:653) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.db.rows.UnfilteredSerializer.deserializeRowBody(UnfilteredSerializer.java:436) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.db.UnfilteredDeserializer$CurrentDeserializer.readNext(UnfilteredDeserializer.java:211) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:266) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:153) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:340) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:369) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:189) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:158) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:428) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:288) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:108) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:128) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133) ~[apache-cassandra-3.0.3.jar:3.0.3] at org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133) ~[apache-cassandra-3.0.3.jar:3.0.3] {quote} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10992) Hanging streaming sessions
[ https://issues.apache.org/jira/browse/CASSANDRA-10992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179850#comment-15179850 ] mlowicki commented on CASSANDRA-10992: -- The same case after upgrade. Hanging streaming sessions visible in OpsCenter and returned by `nodetool netstats`. I've been waiting 2 hours after repair finished. > Hanging streaming sessions > -- > > Key: CASSANDRA-10992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10992 > Project: Cassandra > Issue Type: Bug > Environment: C* 2.1.12, Debian Wheezy >Reporter: mlowicki >Assignee: Paulo Motta > Fix For: 2.1.12 > > Attachments: apache-cassandra-2.1.12-SNAPSHOT.jar > > > I've started recently running repair using [Cassandra > Reaper|https://github.com/spotify/cassandra-reaper] (built-in {{nodetool > repair}} doesn't work for me - CASSANDRA-9935). It behaves fine but I've > noticed hanging streaming sessions: > {code} > root@db1:~# date > Sat Jan 9 16:43:00 UTC 2016 > root@db1:~# nt netstats -H | grep total > Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB > total > Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total > Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB > total > Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total > Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB > total > Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total > Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 > MB total > Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total > Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB > total > Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB > total > root@db1:~# date > Sat Jan 9 17:45:42 UTC 2016 > root@db1:~# nt netstats -H | grep total > Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB > total > Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total > Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB > total > Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total > Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB > total > Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total > Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 > MB total > Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total > Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB > total > Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB > total > {code} > Such sessions are left even when repair job is long time done (confirmed by > checking Reaper's and Cassandra's logs). {{streaming_socket_timeout_in_ms}} > in cassandra.yaml is set to default value (360). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11059) In cqlsh show static columns in a different color
[ https://issues.apache.org/jira/browse/CASSANDRA-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179875#comment-15179875 ] Pavel Trukhanov commented on CASSANDRA-11059: - That's against the trunk. Please see here https://github.com/apache/cassandra/compare/trunk...okmeter:CASSANDRA-11059 But if it works for some previous versions too (need to check that) it still won't be backported — it's the policy, right? Or what? > In cqlsh show static columns in a different color > - > > Key: CASSANDRA-11059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11059 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Environment: [cqlsh 5.0.1 | Cassandra 2.2.3 | CQL spec 3.3.1 | Native > protocol v4] >Reporter: Cédric Hernalsteens >Priority: Minor > Fix For: 3.x > > > The partition key columns are shown in red, the clustering columns in cyan, > it would be great to also distinguish between the static columns and the > other. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10992) Hanging streaming sessions
[ https://issues.apache.org/jira/browse/CASSANDRA-10992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179887#comment-15179887 ] Paulo Motta commented on CASSANDRA-10992: - You're saying the repair finishes successfully, and streaming sessions are still reported as being active, or do the repairs also hang? If that's the case I suspect reaper's might restarting/killing repairs due to timeout, and they're not cleared properly. Can you check if you see any errors/logs in the log again, and also the reaper's log for any retries? In particular, check for any "Terminate session is called", to check if {{StorageService.forceTerminateAllRepairSessions}} is being called by any chance. > Hanging streaming sessions > -- > > Key: CASSANDRA-10992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10992 > Project: Cassandra > Issue Type: Bug > Environment: C* 2.1.12, Debian Wheezy >Reporter: mlowicki >Assignee: Paulo Motta > Fix For: 2.1.12 > > Attachments: apache-cassandra-2.1.12-SNAPSHOT.jar > > > I've started recently running repair using [Cassandra > Reaper|https://github.com/spotify/cassandra-reaper] (built-in {{nodetool > repair}} doesn't work for me - CASSANDRA-9935). It behaves fine but I've > noticed hanging streaming sessions: > {code} > root@db1:~# date > Sat Jan 9 16:43:00 UTC 2016 > root@db1:~# nt netstats -H | grep total > Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB > total > Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total > Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB > total > Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total > Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB > total > Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total > Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 > MB total > Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total > Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB > total > Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB > total > root@db1:~# date > Sat Jan 9 17:45:42 UTC 2016 > root@db1:~# nt netstats -H | grep total > Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB > total > Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total > Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB > total > Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total > Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB > total > Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total > Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 > MB total > Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total > Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB > total > Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB > total > {code} > Such sessions are left even when repair job is long time done (confirmed by > checking Reaper's and Cassandra's logs). {{streaming_socket_timeout_in_ms}} > in cassandra.yaml is set to default value (360). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10091) Align JMX authentication with internal authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179892#comment-15179892 ] Sam Tunnicliffe commented on CASSANDRA-10091: - [~Jan Karlsson] thanks! I've made those changes, plus a couple of other minor tweaks & pushed to my branch. I've also extended your dtest a bit [here|https://github.com/beobal/cassandra-dtest/commits/10091]. > Align JMX authentication with internal authentication > - > > Key: CASSANDRA-10091 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10091 > Project: Cassandra > Issue Type: New Feature >Reporter: Jan Karlsson >Assignee: Sam Tunnicliffe >Priority: Minor > Fix For: 3.x > > > It would be useful to authenticate with JMX through Cassandra's internal > authentication. This would reduce the overhead of keeping passwords in files > on the machine and would consolidate passwords to one location. It would also > allow the possibility to handle JMX permissions in Cassandra. > It could be done by creating our own JMX server and setting custom classes > for the authenticator and authorizer. We could then add some parameters where > the user could specify what authenticator and authorizer to use in case they > want to make their own. > This could also be done by creating a premain method which creates a jmx > server. This would give us the feature without changing the Cassandra code > itself. However I believe this would be a good feature to have in Cassandra. > I am currently working on a solution which creates a JMX server and uses a > custom authenticator and authorizer. It is currently build as a premain, > however it would be great if we could put this in Cassandra instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10707) Add support for Group By to Select statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179895#comment-15179895 ] Benjamin Lerer commented on CASSANDRA-10707: ||patch||utests||dtests|| |[trunk|https://github.com/apache/cassandra/compare/trunk...blerer:10707-trunk]|[trunk|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10707-trunk-testall/]|[trunk|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10707-trunk-dtest/]| I have pushed new commits to handle the last review comments. The patch does not fix yet the problem of shortRead but the current implementation is definitely broken. As {{countedInCurrentPartition()}} is not overridden the row count is used to compute the number of rows to fetch but the limit is then set in term of groups. I have to take something to properly investigate this problem. {quote}In the news file, you have IN restrictions with only one element are now considered as equality restrictions. What does that mean for the user?{quote} Some queries which use to be rejected will suddenly get accepted like multipartitions-queries with {{ORDER BY}} and paging. Some error messages will also be slightly different. I removed the entry for now as I agree that it might not be fully relevant for the users. > Add support for Group By to Select statement > > > Key: CASSANDRA-10707 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10707 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer > > Now that Cassandra support aggregate functions, it makes sense to support > {{GROUP BY}} on the {{SELECT}} statements. > It should be possible to group either at the partition level or at the > clustering column level. > {code} > SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey; > SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP > BY partitionKey, clustering0, clustering1; > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10992) Hanging streaming sessions
[ https://issues.apache.org/jira/browse/CASSANDRA-10992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179905#comment-15179905 ] mlowicki commented on CASSANDRA-10992: -- Repair finished successfully using Cassandra Reaper. It happened during the whole process (took couple of days) that Reaper terminated some sessions due to timeout (saw that in logs which live watching). > Hanging streaming sessions > -- > > Key: CASSANDRA-10992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10992 > Project: Cassandra > Issue Type: Bug > Environment: C* 2.1.12, Debian Wheezy >Reporter: mlowicki >Assignee: Paulo Motta > Fix For: 2.1.12 > > Attachments: apache-cassandra-2.1.12-SNAPSHOT.jar > > > I've started recently running repair using [Cassandra > Reaper|https://github.com/spotify/cassandra-reaper] (built-in {{nodetool > repair}} doesn't work for me - CASSANDRA-9935). It behaves fine but I've > noticed hanging streaming sessions: > {code} > root@db1:~# date > Sat Jan 9 16:43:00 UTC 2016 > root@db1:~# nt netstats -H | grep total > Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB > total > Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total > Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB > total > Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total > Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB > total > Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total > Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 > MB total > Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total > Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB > total > Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB > total > root@db1:~# date > Sat Jan 9 17:45:42 UTC 2016 > root@db1:~# nt netstats -H | grep total > Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB > total > Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total > Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB > total > Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total > Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB > total > Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total > Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 > MB total > Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total > Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB > total > Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB > total > {code} > Such sessions are left even when repair job is long time done (confirmed by > checking Reaper's and Cassandra's logs). {{streaming_socket_timeout_in_ms}} > in cassandra.yaml is set to default value (360). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11304) Stack overflow when querying 2ndary index
[ https://issues.apache.org/jira/browse/CASSANDRA-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-11304: - Assignee: Sam Tunnicliffe > Stack overflow when querying 2ndary index > - > > Key: CASSANDRA-11304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11304 > Project: Cassandra > Issue Type: Bug > Components: Core, CQL > Environment: 3 Node cluster / Ubuntu 14.04 / Cassandra 3.0.3 >Reporter: Job Tiel Groenestege >Assignee: Sam Tunnicliffe > > When reading data through a secondary index _select * from tableName where > secIndexField = 'foo'_ (from a Java application) I get the following > stacktrace on all nodes; after the query read fails. It happens repeatably > when I rerun the same query: > {quote} > WARN [SharedPool-Worker-8] 2016-03-04 13:26:28,041 > AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread > Thread[SharedPool-Worker-8,5,main]: {} > java.lang.StackOverflowError: null > at > org.apache.cassandra.db.rows.BTreeRow$Builder.build(BTreeRow.java:653) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredSerializer.deserializeRowBody(UnfilteredSerializer.java:436) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.UnfilteredDeserializer$CurrentDeserializer.readNext(UnfilteredDeserializer.java:211) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:266) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:153) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:340) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:369) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:189) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:158) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:428) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:288) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:108) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:128) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133) > ~[apache-cassandra-3.0.3.jar:3.0.3] > {quote} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11304) Stack overflow when querying 2ndary index
[ https://issues.apache.org/jira/browse/CASSANDRA-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-11304: - Summary: Stack overflow when querying 2ndary index (was: Query data through a secondary index) > Stack overflow when querying 2ndary index > - > > Key: CASSANDRA-11304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11304 > Project: Cassandra > Issue Type: Bug > Components: Core, CQL > Environment: 3 Node cluster / Ubuntu 14.04 / Cassandra 3.0.3 >Reporter: Job Tiel Groenestege > > When reading data through a secondary index _select * from tableName where > secIndexField = 'foo'_ (from a Java application) I get the following > stacktrace on all nodes; after the query read fails. It happens repeatably > when I rerun the same query: > {quote} > WARN [SharedPool-Worker-8] 2016-03-04 13:26:28,041 > AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread > Thread[SharedPool-Worker-8,5,main]: {} > java.lang.StackOverflowError: null > at > org.apache.cassandra.db.rows.BTreeRow$Builder.build(BTreeRow.java:653) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredSerializer.deserializeRowBody(UnfilteredSerializer.java:436) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.UnfilteredDeserializer$CurrentDeserializer.readNext(UnfilteredDeserializer.java:211) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:266) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:153) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:340) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:369) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:189) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:158) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:428) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:288) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:108) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:128) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133) > ~[apache-cassandra-3.0.3.jar:3.0.3] > {quote} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11304) Stack overflow when querying 2ndary index
[ https://issues.apache.org/jira/browse/CASSANDRA-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179910#comment-15179910 ] Sam Tunnicliffe commented on CASSANDRA-11304: - Can you share the schema of indexed table? > Stack overflow when querying 2ndary index > - > > Key: CASSANDRA-11304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11304 > Project: Cassandra > Issue Type: Bug > Components: Core, CQL > Environment: 3 Node cluster / Ubuntu 14.04 / Cassandra 3.0.3 >Reporter: Job Tiel Groenestege >Assignee: Sam Tunnicliffe > > When reading data through a secondary index _select * from tableName where > secIndexField = 'foo'_ (from a Java application) I get the following > stacktrace on all nodes; after the query read fails. It happens repeatably > when I rerun the same query: > {quote} > WARN [SharedPool-Worker-8] 2016-03-04 13:26:28,041 > AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread > Thread[SharedPool-Worker-8,5,main]: {} > java.lang.StackOverflowError: null > at > org.apache.cassandra.db.rows.BTreeRow$Builder.build(BTreeRow.java:653) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredSerializer.deserializeRowBody(UnfilteredSerializer.java:436) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.UnfilteredDeserializer$CurrentDeserializer.readNext(UnfilteredDeserializer.java:211) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:266) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:153) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:340) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:369) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:189) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:158) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:428) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:288) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:108) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:128) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133) > ~[apache-cassandra-3.0.3.jar:3.0.3] > {quote} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11305) Customization of the auto granting process
Alexandre Linte created CASSANDRA-11305: --- Summary: Customization of the auto granting process Key: CASSANDRA-11305 URL: https://issues.apache.org/jira/browse/CASSANDRA-11305 Project: Cassandra Issue Type: New Feature Components: CQL Environment: Apache Cassandra 3.3, cqlsh 5.0.1, CQL spec 3.4.0 Reporter: Alexandre Linte Priority: Minor Fix For: 3.3 Hello, By default, Cassandra implements an auto granting process which is applied when a USER | ROLE does a CREATE KEYSPACE, CREATE TABLE, CREATE FUNCTION, CREATE AGGREGATE or CREATE ROLE statement. The creator is automatically granted all applicable permissions on the new resource. For example, the ROLE "toto_user" is created and has CREATE permission on its personal KEYSPACE "toto_keyspace". Today when toto_user create a TABLE, he is automatically granted the following rights: * ALTER * DROP * SELECT * MODIFY * AUTHORIZE Moreover if you want to REVOKE a permission for "toto_user" on a table, this table must exist. The idea of the issue is to improve the auto granting process. I thought about a modification of the REVOKE and GRANT SQL commands. You can find below the syntax part: {noformat} ::= GRANT ( ALL ( PERMISSIONS )? | ( PERMISSION )? ) ON TO ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE | DESRIBE | EXECUTE ::= ALL KEYSPACES | KEYSPACE | ( TABLE )? | ALL ROLES | ROLE | ALL FUNCTIONS ( IN KEYSPACE )? | FUNCTION ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE ) {noformat} {noformat} ::= REVOKE ( ALL ( PERMISSIONS )? | ( PERMISSION )? ) ON FROM ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE | DESRIBE | EXECUTE ::= ALL KEYSPACES | KEYSPACE | ( TABLE )? | ALL ROLES | ROLE | ALL FUNCTIONS ( IN KEYSPACE )? | FUNCTION ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE ) {noformat} And now multiple the samples part: {noformat} GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user; => default functioning, when toto_user creates a table he will be automatically granted all permissions. GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE TABLE; => grant all permissions to the resource (table) created by toto_user on the keyspace toto_keyspace. GRANT SELECT ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE TABLE; => grant select permission to the resource (table) created by toto_user on the keyspace toto_keyspace. REVOKE ALL PERMISSIONS ON KEYSPACE toto_keyspace FROM toto_user; => default functioning, toto_user will not be able to do something on the keyspace toto_keyspace. REVOKE AUTHORIZE PERMISSION ON KEYSPACE toto_keyspace FROM toto_user WHEN CREATE TABLE; => revoke authorize permission to the resource (table) created by toto_user on the keyspace toto_keyspace. REVOKE DROP PERMISSION ALL KEYSPACES FROM toto_user WHEN CREATE ROLE; => revoke drop permission to the resource (role) created by toto_user on the keyspace toto_keyspace. {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10992) Hanging streaming sessions
[ https://issues.apache.org/jira/browse/CASSANDRA-10992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179938#comment-15179938 ] Paulo Motta commented on CASSANDRA-10992: - What is the reaper timeout? Could you try increasing these significantly and check if the repair/streams will still hang? I suspect original repairs are just slow but are being aborted by reaper, and currently streams are not stopped when repair is aborted, so when the new repair is submitted for the same range new stream sessions will make the previous stream sessions hang for some reasons (resource locking or whatever). Proper repair cleanup on abort will be implemented on CASSANDRA-11190 and should fix those if that's the case. > Hanging streaming sessions > -- > > Key: CASSANDRA-10992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10992 > Project: Cassandra > Issue Type: Bug > Environment: C* 2.1.12, Debian Wheezy >Reporter: mlowicki >Assignee: Paulo Motta > Fix For: 2.1.12 > > Attachments: apache-cassandra-2.1.12-SNAPSHOT.jar > > > I've started recently running repair using [Cassandra > Reaper|https://github.com/spotify/cassandra-reaper] (built-in {{nodetool > repair}} doesn't work for me - CASSANDRA-9935). It behaves fine but I've > noticed hanging streaming sessions: > {code} > root@db1:~# date > Sat Jan 9 16:43:00 UTC 2016 > root@db1:~# nt netstats -H | grep total > Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB > total > Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total > Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB > total > Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total > Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB > total > Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total > Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 > MB total > Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total > Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB > total > Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB > total > root@db1:~# date > Sat Jan 9 17:45:42 UTC 2016 > root@db1:~# nt netstats -H | grep total > Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB > total > Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total > Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB > total > Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total > Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB > total > Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total > Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 > MB total > Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total > Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB > total > Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB > total > {code} > Such sessions are left even when repair job is long time done (confirmed by > checking Reaper's and Cassandra's logs). {{streaming_socket_timeout_in_ms}} > in cassandra.yaml is set to default value (360). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-11210) Unresolved hostname in replace address
[ https://issues.apache.org/jira/browse/CASSANDRA-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Karlsson reassigned CASSANDRA-11210: Assignee: Jan Karlsson > Unresolved hostname in replace address > -- > > Key: CASSANDRA-11210 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11210 > Project: Cassandra > Issue Type: Bug >Reporter: sankalp kohli >Assignee: Jan Karlsson >Priority: Minor > Labels: lhf > > If you provide a hostname which could not be resolved by DNS, it leads to > replace args being ignored. If you provide an IP which is not in the cluster, > it does the right thing and complain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11304) Stack overflow when querying 2ndary index
[ https://issues.apache.org/jira/browse/CASSANDRA-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179955#comment-15179955 ] Job Tiel Groenestege commented on CASSANDRA-11304: -- Modified some column-names - manually - for readability so I could accidentally have created duplicate row names; the original names are a bit longer (but I assume that is not the issue here) {quote} CREATE TABLE keyspace.tablename ( t ascii, time timestamp, aid ascii, adid int, ap int, adc ascii, aiseid ascii, aisip boolean, bpacn int, bppcn int, bpusn int, bcacn int, bcpcn int, bcun int, bid int, btom int, cid int, c ascii, cacacn int, cacpcn int, cacun int, cac2acn int, cac2pcn int, cacun int, cac3acn int, cac3pcn int, cac3un int, cac4acn int, cac4pcn int, cac4un int, cac5acn int, cac5pcn int, cac5un int, crid int, dcacn int, dcpcn int, dcun int, dt int, dc ascii, du ascii, est ascii, et bigint, evt ascii, ex ascii, fp uuid, flid int, grid int, ioid int, ip ascii, isp_id int, l ascii, liid int, mtk text, mts ascii, mmid int, mmid int, ns int, osid int, pracn int, prpcn int, prusn int, pmac1acn int, pmac1pcn int, pmac1un int, pmac2acn int, pmac2pcn int, pmac2un int, pmac3acn int, pmac3pcn int, pmac3un int, pmac4acn int, pmac4pcn int, pmac5un int, pmac5acn int, pmac5pcn int, pmac6un int, pc ascii, rt bigint, tmcacn int, tmcpcn int, tmcun int, usid int, url text, vt bigint, wpacn int, wppcn int, wpusn int, PRIMARY KEY (uid, time, aid, adid) ) WITH CLUSTERING ORDER BY (time ASC, aid ASC, adid ASC) AND bloom_filter_fp_chance = 0.01 AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND comment = '' AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'} AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'} AND crc_check_chance = 1.0 AND dclocal_read_repair_chance = 0.1 AND default_time_to_live = 0 AND gc_grace_seconds = 864000 AND max_index_interval = 2048 AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128 AND read_repair_chance = 0.0 AND speculative_retry = '99PERCENTILE'; CREATE INDEX fileindex ON keyspace.tablename (fp); {quote} > Stack overflow when querying 2ndary index > - > > Key: CASSANDRA-11304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11304 > Project: Cassandra > Issue Type: Bug > Components: Core, CQL > Environment: 3 Node cluster / Ubuntu 14.04 / Cassandra 3.0.3 >Reporter: Job Tiel Groenestege >Assignee: Sam Tunnicliffe > > When reading data through a secondary index _select * from tableName where > secIndexField = 'foo'_ (from a Java application) I get the following > stacktrace on all nodes; after the query read fails. It happens repeatably > when I rerun the same query: > {quote} > WARN [SharedPool-Worker-8] 2016-03-04 13:26:28,041 > AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread > Thread[SharedPool-Worker-8,5,main]: {} > java.lang.StackOverflowError: null > at > org.apache.cassandra.db.rows.BTreeRow$Builder.build(BTreeRow.java:653) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredSerializer.deserializeRowBody(UnfilteredSerializer.java:436) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.UnfilteredDeserializer$CurrentDeserializer.readNext(UnfilteredDeserializer.java:211) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:266) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:153) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:340) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.ja
[jira] [Commented] (CASSANDRA-11258) Repair scheduling - Resource locking API
[ https://issues.apache.org/jira/browse/CASSANDRA-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179980#comment-15179980 ] Marcus Olsson commented on CASSANDRA-11258: --- bq. WDYT of this approach? I like it, it would reduce the amount of work for the write operations while keeping a simple structure of the lock keyspace. However, *if* we want to visualize all data center locks to the user, it would be more complex to do so. bq. If you like this approach, we could do the initial version assuming a single DC with SimpleStrategy replication + SERIAL consistency, while power users could still have multi-DC support by manually changing replication settings of the lock keyspace. We could later add transparent/efficient multi-DC support via CASSANDRA-11300 and LocalDataCenterReplicationStrategy. +1 Should we start with {{SimpleStrategy}} and a replication of 3 then? If we only have one node there would be no need for repairs and if we have two it would be possible to do CAS requests. If we include the {{LocalDataCenterReplicationStrategy}} class directly in the first version but use SimpleStrategy until CASSANDRA-11300 is in place it should be possible to switch to LDCRS automatically later on, assuming that repairs would be paused during that upgrade. If we don't include LDCRS directly I think the switch would either have to be manual or done by first verifying the version of the other nodes, so that the "older" nodes wouldn't complain about an unknown replication class. > Repair scheduling - Resource locking API > > > Key: CASSANDRA-11258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11258 > Project: Cassandra > Issue Type: Sub-task >Reporter: Marcus Olsson >Assignee: Marcus Olsson >Priority: Minor > > Create a resource locking API & implementation that is able to lock a > resource in a specified data center. It should handle priorities to avoid > node starvation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10750) Minor code improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-10750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179981#comment-15179981 ] Sylvain Lebresne commented on CASSANDRA-10750: -- Can you please dig up in which release this made it in for history sake? > Minor code improvements > --- > > Key: CASSANDRA-10750 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10750 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Minor > > Went though several IDE inspections and found some places in the code that > could be improved. These are just minor improvements and no bug fixes (except > one minor "theoretical" thing). > The [branch on github against > trunk|https://github.com/snazy/cassandra/tree/10750-code-opts-trunk] contains > a series of commits: > * simplify Mutation.apply to remove the casts > * "minor code improvements" just replaces some expressions that are > effectively constant > * remove unused assignments (probably just cosmetic) > * collapse identical if-branches (probably just cosmetic) > * empty array constants > * fix printf usage (could potentially raise an exception in printf) > * replace tail-recursion in some critical sections (as the JVM cannot > optimize that AFAIK) > * remove methods identical to their super methods (probably just cosmetic) > [cassci results > here|http://cassci.datastax.com/view/Dev/view/snazy/search/?q=snazy-10750-] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11304) Stack overflow when querying 2ndary index
[ https://issues.apache.org/jira/browse/CASSANDRA-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179983#comment-15179983 ] Sylvain Lebresne commented on CASSANDRA-11304: -- For info, seems the recursive call to {{prepareNext}} that is the cause of this has already been fixed on trunk by CASSANDRA-10750 (which somehow doesn't have a proper fix version) but not on 3.0. We might just want to backport that change here. > Stack overflow when querying 2ndary index > - > > Key: CASSANDRA-11304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11304 > Project: Cassandra > Issue Type: Bug > Components: Core, CQL > Environment: 3 Node cluster / Ubuntu 14.04 / Cassandra 3.0.3 >Reporter: Job Tiel Groenestege >Assignee: Sam Tunnicliffe > > When reading data through a secondary index _select * from tableName where > secIndexField = 'foo'_ (from a Java application) I get the following > stacktrace on all nodes; after the query read fails. It happens repeatably > when I rerun the same query: > {quote} > WARN [SharedPool-Worker-8] 2016-03-04 13:26:28,041 > AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread > Thread[SharedPool-Worker-8,5,main]: {} > java.lang.StackOverflowError: null > at > org.apache.cassandra.db.rows.BTreeRow$Builder.build(BTreeRow.java:653) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredSerializer.deserializeRowBody(UnfilteredSerializer.java:436) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.UnfilteredDeserializer$CurrentDeserializer.readNext(UnfilteredDeserializer.java:211) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:266) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:153) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:340) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:369) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:189) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:158) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:428) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:288) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:108) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:128) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133) > ~[apache-cassandra-3.0.3.jar:3.0.3] > at > org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133) > ~[apache-cassandra-3.0.3.jar:3.0.3] > {quote} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11302) Invalid time unit conversion causing write timeouts
[ https://issues.apache.org/jira/browse/CASSANDRA-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179988#comment-15179988 ] Ariel Weisberg edited comment on CASSANDRA-11302 at 3/4/16 3:07 PM: Yes that is an issue. There is an isTimedOut method on QueuedMessage that could probably be made to do the conversion and be called from all the locations that want to check the timeout. The attached patch would fix the bug, but I think we should put this in a helper so the next time the units change we only have to update one line. was (Author: aweisberg): Yes that is the issue. There is an isTimedOut method on QueuedMessage that could probably be made to do the conversion and be called from all the locations that want to check the timeout. > Invalid time unit conversion causing write timeouts > --- > > Key: CASSANDRA-11302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11302 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Mike Heffner > Attachments: nanosec.patch > > > We've been debugging a write timeout that we saw after upgrading from the > 2.0.x release line, with our particular workload. Details of that process can > be found in this thread: > https://www.mail-archive.com/user@cassandra.apache.org/msg46064.html > After bisecting various patch release versions, and then commits, on the > 2.1.x release line we've identified version 2.1.5 and this commit as the > point where the timeouts first start appearing: > https://github.com/apache/cassandra/commit/828496492c51d7437b690999205ecc941f41a0a9 > After examining the commit we believe this line was a typo: > https://github.com/apache/cassandra/commit/828496492c51d7437b690999205ecc941f41a0a9#diff-c7ef124561c4cde1c906f28ad3883a88L467 > as it doesn't properly convert the timeout value from milliseconds to > nanoseconds. > After testing with the attached patch applied, we do not see timeouts on > version 2.1.5 nor against 2.2.5 when we bring the patch forward. While we've > tested our workload against this and we are fairly confident in the patch, we > are not experts with the code base so we would prefer additional review. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11302) Invalid time unit conversion causing write timeouts
[ https://issues.apache.org/jira/browse/CASSANDRA-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179988#comment-15179988 ] Ariel Weisberg commented on CASSANDRA-11302: Yes that is the issue. There is an isTimedOut method on QueuedMessage that could probably be made to do the conversion and be called from all the locations that want to check the timeout. > Invalid time unit conversion causing write timeouts > --- > > Key: CASSANDRA-11302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11302 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Mike Heffner > Attachments: nanosec.patch > > > We've been debugging a write timeout that we saw after upgrading from the > 2.0.x release line, with our particular workload. Details of that process can > be found in this thread: > https://www.mail-archive.com/user@cassandra.apache.org/msg46064.html > After bisecting various patch release versions, and then commits, on the > 2.1.x release line we've identified version 2.1.5 and this commit as the > point where the timeouts first start appearing: > https://github.com/apache/cassandra/commit/828496492c51d7437b690999205ecc941f41a0a9 > After examining the commit we believe this line was a typo: > https://github.com/apache/cassandra/commit/828496492c51d7437b690999205ecc941f41a0a9#diff-c7ef124561c4cde1c906f28ad3883a88L467 > as it doesn't properly convert the timeout value from milliseconds to > nanoseconds. > After testing with the attached patch applied, we do not see timeouts on > version 2.1.5 nor against 2.2.5 when we bring the patch forward. While we've > tested our workload against this and we are fairly confident in the patch, we > are not experts with the code base so we would prefer additional review. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10707) Add support for Group By to Select statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179992#comment-15179992 ] Brian Hess commented on CASSANDRA-10707: - A quick question/clarification on the GROUP BY and ORDER BY discussion from above. The following are valid SQL: {code:SQL} SELECT pkey, ccol1, Max(x) As maxx FROM myTable GROUP BY pkey, ccol1 ORDER BY ccol1 pkey; SELECT pkey, ccol1, Max(x) As maxx FROM myTable GROUP BY pkey, ccol1 ORDER BY maxx; {code} I think you are suggesting that the only real ordering that is allowed is the native ordering in the CQL tables. Specifically, these 2 queries would not be supported. Is that correct? I think the logic is more like that the following CQL {code:SQL} SELECT pkey, ccol1 Max(x) AS maxx FROM myTable GROUP BY pkey, ccol1 ORDER BY pkey, ccol1 {code} turns into {code:SQL} SELECT pkey, ccol1, Max(x) AS maxx FROM ( SELECT pkey, ccol1, x FROM myTable ORDER BY pkey, ccol1 ) AS sub1 GROUP BY pkey, ccol1; {code} That means that the ORDER BY clause must work in that inner query as valid CQL. More generally: {code:SQL} SELECT [grouping columns], [aggregate function]([aggregate columns]) FROM [table] GROUP BY [grouping columns] ORDER BY [ordering columns] {code} Must satisfy the transformation to: {code:SQL} SELECT [grouping columns], [aggregate function]([aggregate columns]) FROM ( SELECT [grouping columns], [aggregate columns] FROM [table] ORDER BY [ordering columns] ) AS sub1 GROUP BY [grouping columns] {code} And specifically that the inner sub-query is valid CQL, namely: {code:SQL} SELECT [grouping columns], [aggregate columns] FROM [table] ORDER BY [ordering columns] {code} That is certainly different than SQL, which does not have this restriction. I'm +0.5 on having the syntax be the same as SQL as I think it is slightly better than the alternative. I'm just noting that the semantics really are a bit different and there are more restrictions with the ORDER BY clause in CQL with this ticket than in SQL. That nuance needs to be called out in the documentation or folks will certainly run into the error. I would also add that if someone uses an incorrect ORDER BY, the error should not only call out that it is an error, but also indicate what sorts of ORDER BY clauses are supported. > Add support for Group By to Select statement > > > Key: CASSANDRA-10707 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10707 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer > > Now that Cassandra support aggregate functions, it makes sense to support > {{GROUP BY}} on the {{SELECT}} statements. > It should be possible to group either at the partition level or at the > clustering column level. > {code} > SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey; > SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP > BY partitionKey, clustering0, clustering1; > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11059) In cqlsh show static columns in a different color
[ https://issues.apache.org/jira/browse/CASSANDRA-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-11059: Reviewer: Yuki Morishita > In cqlsh show static columns in a different color > - > > Key: CASSANDRA-11059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11059 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Environment: [cqlsh 5.0.1 | Cassandra 2.2.3 | CQL spec 3.3.1 | Native > protocol v4] >Reporter: Cédric Hernalsteens >Priority: Minor > Fix For: 3.x > > > The partition key columns are shown in red, the clustering columns in cyan, > it would be great to also distinguish between the static columns and the > other. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11295) Make custom filtering more extensible via custom classes
[ https://issues.apache.org/jira/browse/CASSANDRA-11295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-11295: - Reviewer: Sylvain Lebresne > Make custom filtering more extensible via custom classes > - > > Key: CASSANDRA-11295 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11295 > Project: Cassandra > Issue Type: Improvement > Components: Local Write-Read Paths >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Minor > Fix For: 3.x > > > At the moment, the implementation of {{RowFilter.CustomExpression}} is > tightly bound to the syntax designed to support non-CQL search syntax for > custom 2i implementations. It might be interesting to decouple the two things > by making the custom expression implementation and serialization a bit more > pluggable. This would allow users to add their own custom expression > implementations to experiment with custom filtering strategies without having > to patch the C* source. As a minimally invasive first step, custom > expressions could be added programmatically via {{QueryHandler}}. Further > down the line, if this proves useful and we can figure out some reasonable > syntax we could think about adding the capability in CQL in a separate > ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11210) Unresolved hostname in replace address
[ https://issues.apache.org/jira/browse/CASSANDRA-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Karlsson updated CASSANDRA-11210: - Fix Version/s: 2.2.6 Status: Patch Available (was: Open) This should apply cleanly to 3.0/trunk except for the Changelog. > Unresolved hostname in replace address > -- > > Key: CASSANDRA-11210 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11210 > Project: Cassandra > Issue Type: Bug >Reporter: sankalp kohli >Assignee: Jan Karlsson >Priority: Minor > Labels: lhf > Fix For: 2.2.6 > > > If you provide a hostname which could not be resolved by DNS, it leads to > replace args being ignored. If you provide an IP which is not in the cluster, > it does the right thing and complain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11294) Provide better documentation for caching
[ https://issues.apache.org/jira/browse/CASSANDRA-11294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-11294: - Issue Type: Improvement (was: Bug) > Provide better documentation for caching > > > Key: CASSANDRA-11294 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11294 > Project: Cassandra > Issue Type: Improvement >Reporter: Benjamin Lerer >Priority: Minor > > I realized that the way caching works in C* is not properly documented. For > example the row cache will only be populated for single partition or > multi-partitions queries and not range queries. It will also never be > populated by secondary index queries even if they are single partition or > multi-partitions queries. > The documentation should be improved to allow people to fully understand how > caching works. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11092) EXPAND breaks when the result has 0 rows in cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-11092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-11092: Reviewer: Tyler Hobbs > EXPAND breaks when the result has 0 rows in cqlsh > - > > Key: CASSANDRA-11092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11092 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Kishan Karunaratne >Assignee: Yuki Morishita >Priority: Trivial > Labels: cqlsh > Fix For: 2.2.x, 3.0.x, 3.x > > > {noformat} > cqlsh> EXPAND ON; > Now Expanded output is enabled > cqlsh> select * from system.local; > @ Row 1 > -+- > key | local > bootstrapped| COMPLETED > broadcast_address | 127.0.0.1 > cluster_name| dse_50_graph > cql_version | 3.4.0 > data_center | Graph > dse_version | 5.0.0 > gossip_generation | 1454032824 > graph | True > host_id | ad30ccb2-04a1-4511-98b6-a72e4ea182c0 > listen_address | 127.0.0.1 > native_protocol_version | 4 > partitioner | org.apache.cassandra.dht.Murmur3Partitioner > rack| rack1 > release_version | 3.0.1.816 > rpc_address | 127.0.0.1 > schema_version | 5667501a-4ac3-3f00-ab35-9040efb927ad > server_id | A0-CE-C8-01-CC-CA > thrift_version | 20.1.0 > tokens | {'-9223372036854775808'} > truncated_at| null > workload| Cassandra > (1 rows) > cqlsh> select * from system.peers; > max() arg is an empty sequence > cqlsh> EXPAND OFF; > Disabled Expanded output. > cqlsh> select * from system.peers; > peer | data_center | dse_version | graph | host_id | preferred_ip | rack | > release_version | rpc_address | schema_version | server_id | tokens | workload > --+-+-+---+-+--+--+-+-++---++-- > (0 rows) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11210) Unresolved hostname in replace address
[ https://issues.apache.org/jira/browse/CASSANDRA-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Karlsson updated CASSANDRA-11210: - Attachment: 0001-Unresolved-hostname-leads-to-replace-being-ignored.patch > Unresolved hostname in replace address > -- > > Key: CASSANDRA-11210 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11210 > Project: Cassandra > Issue Type: Bug >Reporter: sankalp kohli >Assignee: Jan Karlsson >Priority: Minor > Labels: lhf > Fix For: 2.2.6 > > Attachments: > 0001-Unresolved-hostname-leads-to-replace-being-ignored.patch > > > If you provide a hostname which could not be resolved by DNS, it leads to > replace args being ignored. If you provide an IP which is not in the cluster, > it does the right thing and complain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11306) Add support for ALTER INDEX command
Jacques-Henri Berthemet created CASSANDRA-11306: --- Summary: Add support for ALTER INDEX command Key: CASSANDRA-11306 URL: https://issues.apache.org/jira/browse/CASSANDRA-11306 Project: Cassandra Issue Type: Wish Components: Core, CQL Environment: Cassandra 2.2+ Reporter: Jacques-Henri Berthemet Cassandra supports passing options to a (custom) secondary index at creation time: https://docs.datastax.com/en/cql/3.1/cql/cql_reference/create_index_r.html {code} CREATE CUSTOM INDEX ON users (email) USING 'path.to.the.IndexClass' WITH OPTIONS = {'storage': '/mnt/ssd/indexes/'}; {code} However it is not possible to update the options for an existing index. It would be great to have an ALTER INDEX command similar to the ALTER TABLE command. Custom index implementation would receive the command and act accordingly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11210) Unresolved hostname in replace address
[ https://issues.apache.org/jira/browse/CASSANDRA-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-11210: -- Reviewer: sankalp kohli > Unresolved hostname in replace address > -- > > Key: CASSANDRA-11210 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11210 > Project: Cassandra > Issue Type: Bug >Reporter: sankalp kohli >Assignee: Jan Karlsson >Priority: Minor > Labels: lhf > Fix For: 2.2.6 > > Attachments: > 0001-Unresolved-hostname-leads-to-replace-being-ignored.patch > > > If you provide a hostname which could not be resolved by DNS, it leads to > replace args being ignored. If you provide an IP which is not in the cluster, > it does the right thing and complain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11210) Unresolved hostname in replace address
[ https://issues.apache.org/jira/browse/CASSANDRA-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180395#comment-15180395 ] sankalp kohli commented on CASSANDRA-11210: --- +1. > Unresolved hostname in replace address > -- > > Key: CASSANDRA-11210 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11210 > Project: Cassandra > Issue Type: Bug >Reporter: sankalp kohli >Assignee: Jan Karlsson >Priority: Minor > Labels: lhf > Fix For: 2.2.6 > > Attachments: > 0001-Unresolved-hostname-leads-to-replace-being-ignored.patch > > > If you provide a hostname which could not be resolved by DNS, it leads to > replace args being ignored. If you provide an IP which is not in the cluster, > it does the right thing and complain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11210) Unresolved hostname in replace address
[ https://issues.apache.org/jira/browse/CASSANDRA-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-11210: -- Status: Ready to Commit (was: Patch Available) > Unresolved hostname in replace address > -- > > Key: CASSANDRA-11210 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11210 > Project: Cassandra > Issue Type: Bug >Reporter: sankalp kohli >Assignee: Jan Karlsson >Priority: Minor > Labels: lhf > Fix For: 2.2.6 > > Attachments: > 0001-Unresolved-hostname-leads-to-replace-being-ignored.patch > > > If you provide a hostname which could not be resolved by DNS, it leads to > replace args being ignored. If you provide an IP which is not in the cluster, > it does the right thing and complain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7928) Digest queries do not require alder32 checks
[ https://issues.apache.org/jira/browse/CASSANDRA-7928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180397#comment-15180397 ] sankalp kohli commented on CASSANDRA-7928: -- Sure close it. > Digest queries do not require alder32 checks > > > Key: CASSANDRA-7928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7928 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Priority: Minor > Labels: performance > Fix For: 3.x > > > While reading data from sstables, C* does Alder32 checks for any data being > read. We have seen that this causes higher CPU usage while doing kernel > profiling. These checks might not be useful for digest queries as they will > have a different digest in case of corruption. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6377) ALLOW FILTERING should allow seq scan filtering
[ https://issues.apache.org/jira/browse/CASSANDRA-6377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180478#comment-15180478 ] Benjamin Lerer commented on CASSANDRA-6377: --- As filtering on non primary-key columns for queries without secondary index was already supported since 3.0 (as a side effect of CASSANDRA-8099) and the patches for 3.0 and 3.x mostly fixes some issues with validation and filtering on static columns. I think it is best to push the patches into {{3.0.5}} and {{3.5}}. > ALLOW FILTERING should allow seq scan filtering > --- > > Key: CASSANDRA-6377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6377 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Jonathan Ellis >Assignee: Benjamin Lerer > Labels: cql > Fix For: 3.0.x, 3.x > > > CREATE TABLE emp_table2 ( > empID int PRIMARY KEY, > firstname text, > lastname text, > b_mon text, > b_day text, > b_yr text, > ); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (100,'jane','doe','oct','31','1980'); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (101,'john','smith','jan','01','1981'); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (102,'mary','jones','apr','15','1982'); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (103,'tim','best','oct','25','1982'); > > SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2 > WHERE b_mon='oct' ALLOW FILTERING; > Bad Request: No indexed columns present in by-columns clause with Equal > operator -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9117) LEAK DETECTED during repair, startup
[ https://issues.apache.org/jira/browse/CASSANDRA-9117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180494#comment-15180494 ] Sebastian Estevez commented on CASSANDRA-9117: -- For future reference I ended up openning CASSANDRA-10079 and it's fixed in 2.1.12 > LEAK DETECTED during repair, startup > > > Key: CASSANDRA-9117 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9117 > Project: Cassandra > Issue Type: Bug >Reporter: Tyler Hobbs >Assignee: Marcus Eriksson > Fix For: 2.2.0 beta 1 > > Attachments: > 0001-dont-initialize-writer-before-checking-if-iter-is-em.patch, node1.log, > node2.log.gz > > > When running the > {{incremental_repair_test.TestIncRepair.multiple_repair_test}} dtest, the > following error logs show up: > {noformat} > ERROR [Reference-Reaper:1] 2015-04-03 15:48:25,491 Ref.java:181 - LEAK > DETECTED: a reference > (org.apache.cassandra.utils.concurrent.Ref$State@83f047e) to class > org.apache.cassandra.io.util.SafeMemory$MemoryTidy@1631580268:Memory@[7f354800bdc0..7f354800bde8) > was not released before the reference was garbage collected > ERROR [Reference-Reaper:1] 2015-04-03 15:48:25,493 Ref.java:181 - LEAK > DETECTED: a reference > (org.apache.cassandra.utils.concurrent.Ref$State@50bc8f67) to class > org.apache.cassandra.io.util.SafeMemory$MemoryTidy@191552666:Memory@[7f354800ba90..7f354800bdb0) > was not released before the reference was garbage collected > ERROR [Reference-Reaper:1] 2015-04-03 15:48:25,493 Ref.java:181 - LEAK > DETECTED: a reference > (org.apache.cassandra.utils.concurrent.Ref$State@7fd10877) to class > org.apache.cassandra.io.util.SafeMemory$MemoryTidy@1954741807:Memory@[7f3548101190..7f3548101194) > was not released before the reference was garbage collected > ERROR [Reference-Reaper:1] 2015-04-03 15:48:25,494 Ref.java:181 - LEAK > DETECTED: a reference > (org.apache.cassandra.utils.concurrent.Ref$State@578550ac) to class > org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$1@1903393047:[[OffHeapBitSet]] > was not released before the reference was garbage collected > {noformat} > The test is being run against trunk (commit {{1dff098e}}). I've attached a > DEBUG-level log from the test run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9967) Determine if a Materialized View is finished building, without having to query each node
[ https://issues.apache.org/jira/browse/CASSANDRA-9967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180504#comment-15180504 ] Joel Knighton commented on CASSANDRA-9967: -- Sorry for the delay. utests and dtests look clean compared to upstream. The added dtests pass locally for me. A dtest that covers calling the command after dropping a view would be nice. In SystemKeyspace - Now might be a good time to fix the comment above {{finishViewBuildStatus}} that we discussed ("the build succeeded, but the view build failed") - Changing {{viewBuiltReplicated}} to {{setViewBuiltReplicated}} better matches the naming convention used elsewhere in the class - The {{forceBlockingFlush}} at end of {{viewBuiltReplicated}} is redundant with the call at the end of {{setViewBuilt}} In QueryProcessor - As we discussed, there's other improvements to be made in QueryProcessor for clarity. It seems to me that the {{executeInternal}} you added might not be appropriately named - it calls {{statement.execute}} rather than {{statement.executeInternal}}. (It's not entirely clear whether the internal in QueryProcessor.executeInternal is to reflect that it uses internal QueryState or executeInternal on PreparedStatement, but it seems to me to indicate the latter.) In StorageService - In {{getViewBuildStatuses}}, retrieving the {{hostIdToEndpoint}} map at a different time than calling {{getEndpointToHostIdMapForReading()}} opens up a race with changes in TokenMetadata that could result in the endpoint being null. It seems to me cleaner to retrieve the endpointToHostIdMapForReading and iterate over its entries rather than maintaining two separate maps. > Determine if a Materialized View is finished building, without having to > query each node > > > Key: CASSANDRA-9967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9967 > Project: Cassandra > Issue Type: New Feature >Reporter: Alan Boudreault >Assignee: Carl Yeksigian >Priority: Minor > Labels: lhf > Fix For: 3.x > > > Since MVs are eventually consistent with its base table, It would nice if we > could easily know the state of the MV after its creation, so we could wait > until the MV is built before doing some operations. > // cc [~mbroecheler] [~tjake] [~carlyeks] [~enigmacurry] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[2/2] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families
Fix filtering on non-primary key columns for thrift static column families patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/90fd8dee Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/90fd8dee Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/90fd8dee Branch: refs/heads/cassandra-2.2 Commit: 90fd8deed0d1eaa12906bc80aaf54daf837f3a81 Parents: 0934542 Author: Benjamin Lerer Authored: Fri Mar 4 22:05:13 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:05:13 2016 +0100 -- CHANGES.txt | 2 + .../cassandra/cql3/SingleColumnRelation.java| 4 - .../cql3/restrictions/AbstractRestriction.java | 4 +- .../restrictions/StatementRestrictions.java | 25 +- .../cql3/statements/SelectStatement.java| 8 +- .../db/index/SecondaryIndexManager.java | 43 +- .../entities/FrozenCollectionsTest.java | 4 +- .../validation/entities/SecondaryIndexTest.java | 2 +- .../cql3/validation/entities/UFAuthTest.java| 11 - .../entities/UFIdentificationTest.java | 6 +- .../SelectMultiColumnRelationTest.java | 31 +- .../SelectSingleColumnRelationTest.java | 34 +- .../cql3/validation/operations/SelectTest.java | 829 ++- .../db/index/PerRowSecondaryIndexTest.java | 4 +- 14 files changed, 915 insertions(+), 92 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index db6d79d..5631a28 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,6 @@ 2.2.6 + * Fix filtering on non-primary key columns for thrift static column families + (CASSANDRA-6377) * Only log yaml config once, at startup (CASSANDRA-11217) * Preserve order for preferred SSL cipher suites (CASSANDRA-11164) * Reference leak with parallel repairs on the same table (CASSANDRA-11215) http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java -- diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java index b206631..dbae5f0 100644 --- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java +++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java @@ -196,10 +196,6 @@ public final class SingleColumnRelation extends Relation { ColumnSpecification receiver = columnDef; -checkFalse(columnDef.isCompactValue(), - "Predicates on the non-primary-key column (%s) of a COMPACT table are not yet supported", - columnDef.name); - if (isIN()) { // We only allow IN on the row key and the clustering key so far, never on non-PK columns, and this even if http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java -- diff --git a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java index dac7203..385bfbc 100644 --- a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java +++ b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java @@ -93,8 +93,8 @@ abstract class AbstractRestriction implements Restriction ByteBuffer value) throws InvalidRequestException { -checkNotNull(value, "Unsupported null value for indexed column %s", columnSpec.name); -checkBindValueSet(value, "Unsupported unset value for indexed column %s", columnSpec.name); +checkNotNull(value, "Unsupported null value for column %s", columnSpec.name); +checkBindValueSet(value, "Unsupported unset value for column %s", columnSpec.name); checkFalse(value.remaining() > 0x, "Index expression values may not be larger than 64K"); return value; } http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java -- diff --git a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java index 55c6808..e0cf743 100644 --- a/src/java/org/apache/ca
[1/2] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families
Repository: cassandra Updated Branches: refs/heads/cassandra-2.2 093454205 -> 90fd8deed http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java -- diff --git a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java index 506bdaf..d8cd3c3 100644 --- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java +++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java @@ -24,6 +24,8 @@ import org.junit.Test; import junit.framework.Assert; import org.apache.cassandra.cql3.UntypedResultSet; +import org.apache.cassandra.cql3.restrictions.StatementRestrictions; +import org.apache.cassandra.utils.ByteBufferUtil; import org.apache.cassandra.cql3.CQLTester; import static org.junit.Assert.assertEquals; @@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue; */ public class SelectTest extends CQLTester { +private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65); + @Test public void testSingleClustering() throws Throwable { @@ -387,13 +391,13 @@ public class SelectTest extends CQLTester row("test", 5, set("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", "notPresent")); } @@ -420,13 +424,13 @@ public class SelectTest extends CQLTester row("test", 5, list("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ?", "test", 5, "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", @@ -472,19 +476,19 @@ public class SelectTest extends CQLTester row("test", 5, map("lmn", "foo")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS KEY ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS KEY ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessag
[2/3] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families
Fix filtering on non-primary key columns for thrift static column families patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/90fd8dee Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/90fd8dee Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/90fd8dee Branch: refs/heads/cassandra-3.0 Commit: 90fd8deed0d1eaa12906bc80aaf54daf837f3a81 Parents: 0934542 Author: Benjamin Lerer Authored: Fri Mar 4 22:05:13 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:05:13 2016 +0100 -- CHANGES.txt | 2 + .../cassandra/cql3/SingleColumnRelation.java| 4 - .../cql3/restrictions/AbstractRestriction.java | 4 +- .../restrictions/StatementRestrictions.java | 25 +- .../cql3/statements/SelectStatement.java| 8 +- .../db/index/SecondaryIndexManager.java | 43 +- .../entities/FrozenCollectionsTest.java | 4 +- .../validation/entities/SecondaryIndexTest.java | 2 +- .../cql3/validation/entities/UFAuthTest.java| 11 - .../entities/UFIdentificationTest.java | 6 +- .../SelectMultiColumnRelationTest.java | 31 +- .../SelectSingleColumnRelationTest.java | 34 +- .../cql3/validation/operations/SelectTest.java | 829 ++- .../db/index/PerRowSecondaryIndexTest.java | 4 +- 14 files changed, 915 insertions(+), 92 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index db6d79d..5631a28 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,6 @@ 2.2.6 + * Fix filtering on non-primary key columns for thrift static column families + (CASSANDRA-6377) * Only log yaml config once, at startup (CASSANDRA-11217) * Preserve order for preferred SSL cipher suites (CASSANDRA-11164) * Reference leak with parallel repairs on the same table (CASSANDRA-11215) http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java -- diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java index b206631..dbae5f0 100644 --- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java +++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java @@ -196,10 +196,6 @@ public final class SingleColumnRelation extends Relation { ColumnSpecification receiver = columnDef; -checkFalse(columnDef.isCompactValue(), - "Predicates on the non-primary-key column (%s) of a COMPACT table are not yet supported", - columnDef.name); - if (isIN()) { // We only allow IN on the row key and the clustering key so far, never on non-PK columns, and this even if http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java -- diff --git a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java index dac7203..385bfbc 100644 --- a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java +++ b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java @@ -93,8 +93,8 @@ abstract class AbstractRestriction implements Restriction ByteBuffer value) throws InvalidRequestException { -checkNotNull(value, "Unsupported null value for indexed column %s", columnSpec.name); -checkBindValueSet(value, "Unsupported unset value for indexed column %s", columnSpec.name); +checkNotNull(value, "Unsupported null value for column %s", columnSpec.name); +checkBindValueSet(value, "Unsupported unset value for column %s", columnSpec.name); checkFalse(value.remaining() > 0x, "Index expression values may not be larger than 64K"); return value; } http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java -- diff --git a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java index 55c6808..e0cf743 100644 --- a/src/java/org/apache/ca
[3/3] cassandra git commit: Merge branch cassandra-2.2 into cassandra-3.0
Merge branch cassandra-2.2 into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e01c6dd3 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e01c6dd3 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e01c6dd3 Branch: refs/heads/cassandra-3.0 Commit: e01c6dd3aae90c9eeb4fce7d8dd18123f02fed48 Parents: 19bccb4 90fd8de Author: Benjamin Lerer Authored: Fri Mar 4 22:07:23 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:07:35 2016 +0100 -- --
[1/3] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families
Repository: cassandra Updated Branches: refs/heads/cassandra-3.0 19bccb4ea -> e01c6dd3a http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java -- diff --git a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java index 506bdaf..d8cd3c3 100644 --- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java +++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java @@ -24,6 +24,8 @@ import org.junit.Test; import junit.framework.Assert; import org.apache.cassandra.cql3.UntypedResultSet; +import org.apache.cassandra.cql3.restrictions.StatementRestrictions; +import org.apache.cassandra.utils.ByteBufferUtil; import org.apache.cassandra.cql3.CQLTester; import static org.junit.Assert.assertEquals; @@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue; */ public class SelectTest extends CQLTester { +private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65); + @Test public void testSingleClustering() throws Throwable { @@ -387,13 +391,13 @@ public class SelectTest extends CQLTester row("test", 5, set("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", "notPresent")); } @@ -420,13 +424,13 @@ public class SelectTest extends CQLTester row("test", 5, list("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ?", "test", 5, "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", @@ -472,19 +476,19 @@ public class SelectTest extends CQLTester row("test", 5, map("lmn", "foo")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS KEY ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS KEY ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessag
[1/2] cassandra git commit: Fix filtering on non-primary key columns for queries without index
Repository: cassandra Updated Branches: refs/heads/cassandra-3.0 e01c6dd3a -> 9c3855b5f http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java -- diff --git a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java index 8622c98..a7eeeb8 100644 --- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java +++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java @@ -24,6 +24,8 @@ import org.junit.Test; import junit.framework.Assert; import org.apache.cassandra.cql3.UntypedResultSet; +import org.apache.cassandra.cql3.restrictions.StatementRestrictions; +import org.apache.cassandra.utils.ByteBufferUtil; import org.apache.cassandra.cql3.CQLTester; import static org.junit.Assert.assertEquals; @@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue; */ public class SelectTest extends CQLTester { +private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65); + @Test public void testSingleClustering() throws Throwable { @@ -366,7 +370,7 @@ public class SelectTest extends CQLTester } @Test -public void testSetContains() throws Throwable +public void testSetContainsWithIndex() throws Throwable { createTable("CREATE TABLE %s (account text, id int, categories set, PRIMARY KEY (account, id))"); createIndex("CREATE INDEX ON %s(categories)"); @@ -387,19 +391,19 @@ public class SelectTest extends CQLTester row("test", 5, set("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", "notPresent")); } @Test -public void testListContains() throws Throwable +public void testListContainsWithIndex() throws Throwable { createTable("CREATE TABLE %s (account text, id int, categories list, PRIMARY KEY (account, id))"); createIndex("CREATE INDEX ON %s(categories)"); @@ -420,13 +424,13 @@ public class SelectTest extends CQLTester row("test", 5, list("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ?", "test", 5, "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", @@ -434,7 +438,7 @@ public class SelectTest extends CQLTester } @Test -public void testListContainsWithFiltering() throws Throwable +public void testListContainsWithIndexAndFiltering() throws Throwable { createTable("CREATE TABLE %s (e int PRIMARY KEY, f list, s int)"); createIndex("
[2/2] cassandra git commit: Fix filtering on non-primary key columns for queries without index
Fix filtering on non-primary key columns for queries without index patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9c3855b5 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9c3855b5 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9c3855b5 Branch: refs/heads/cassandra-3.0 Commit: 9c3855b5fd83b9fa9ffb2e5495e43cbea9855dee Parents: e01c6dd Author: Benjamin Lerer Authored: Fri Mar 4 22:09:54 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:09:54 2016 +0100 -- CHANGES.txt |1 + .../cassandra/cql3/SingleColumnRelation.java|4 - .../restrictions/StatementRestrictions.java |8 +- .../cql3/statements/SelectStatement.java| 11 +- .../apache/cassandra/db/filter/RowFilter.java | 51 +- .../index/internal/CassandraIndex.java | 15 + .../entities/FrozenCollectionsTest.java |3 +- .../validation/entities/SecondaryIndexTest.java |3 +- .../cql3/validation/operations/DeleteTest.java | 10 +- .../SelectMultiColumnRelationTest.java | 54 +- .../SelectSingleColumnRelationTest.java | 51 +- .../cql3/validation/operations/SelectTest.java | 1071 +- .../cql3/validation/operations/UpdateTest.java |8 +- .../apache/cassandra/index/CustomIndexTest.java |4 +- .../index/internal/CassandraIndexTest.java | 34 +- 15 files changed, 1205 insertions(+), 123 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 520e66e..7204098 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.0.5 + * Fix filtering on non-primary key columns for queries without index (CASSANDRA-6377) * Fix sstableloader fail when using materialized view (CASSANDRA-11275) Merged from 2.2: * Only log yaml config once, at startup (CASSANDRA-11217) http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java -- diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java index e2c0b79..05ba42d 100644 --- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java +++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java @@ -227,10 +227,6 @@ public final class SingleColumnRelation extends Relation { ColumnSpecification receiver = columnDef; -checkFalse(!columnDef.isPrimaryKeyColumn() && isDense, - "Predicates on the non-primary-key column (%s) of a COMPACT table are not yet supported", - columnDef.name); - if (isIN()) { // We only allow IN on the row key and the clustering key so far, never on non-PK columns, and this even if http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java -- diff --git a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java index 1c7db4e..797b8e4 100644 --- a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java +++ b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java @@ -50,8 +50,10 @@ import static org.apache.cassandra.cql3.statements.RequestValidations.invalidReq */ public final class StatementRestrictions { -public static final String NO_INDEX_FOUND_MESSAGE = -"No supported secondary index found for the non primary key columns restrictions"; +public static final String REQUIRES_ALLOW_FILTERING_MESSAGE = +"Cannot execute this query as it might involve data filtering and " + +"thus may have unpredictable performance. If you want to execute " + +"this query despite the performance unpredictability, use ALLOW FILTERING"; /** * The type of statement @@ -224,7 +226,7 @@ public final class StatementRestrictions if (hasQueriableIndex) usesSecondaryIndexing = true; else if (!useFiltering) -throw invalidRequest(NO_INDEX_FOUND_MESSAGE); +throw invalidRequest(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE); indexRestrictions.add(nonPrimaryKeyRestrictions); } http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apach
[1/6] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families
Repository: cassandra Updated Branches: refs/heads/cassandra-3.5 a8dc14d74 -> 8c83c8eda http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java -- diff --git a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java index 506bdaf..d8cd3c3 100644 --- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java +++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java @@ -24,6 +24,8 @@ import org.junit.Test; import junit.framework.Assert; import org.apache.cassandra.cql3.UntypedResultSet; +import org.apache.cassandra.cql3.restrictions.StatementRestrictions; +import org.apache.cassandra.utils.ByteBufferUtil; import org.apache.cassandra.cql3.CQLTester; import static org.junit.Assert.assertEquals; @@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue; */ public class SelectTest extends CQLTester { +private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65); + @Test public void testSingleClustering() throws Throwable { @@ -387,13 +391,13 @@ public class SelectTest extends CQLTester row("test", 5, set("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", "notPresent")); } @@ -420,13 +424,13 @@ public class SelectTest extends CQLTester row("test", 5, list("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ?", "test", 5, "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", @@ -472,19 +476,19 @@ public class SelectTest extends CQLTester row("test", 5, map("lmn", "foo")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS KEY ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS KEY ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessag
[6/6] cassandra git commit: Merge branch cassandra-3.0 into cassandra-3.5
Merge branch cassandra-3.0 into cassandra-3.5 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8c83c8ed Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8c83c8ed Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8c83c8ed Branch: refs/heads/cassandra-3.5 Commit: 8c83c8edab4f1c23c382bb0ac076cab44d5f4dda Parents: a8dc14d 9c3855b Author: Benjamin Lerer Authored: Fri Mar 4 22:12:33 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:13:35 2016 +0100 -- CHANGES.txt |1 + .../cassandra/cql3/SingleColumnRelation.java|4 - .../restrictions/StatementRestrictions.java | 25 +- .../cql3/statements/SelectStatement.java| 12 +- .../apache/cassandra/db/filter/RowFilter.java | 50 +- .../index/internal/CassandraIndex.java | 23 +- .../entities/FrozenCollectionsTest.java |3 +- .../validation/entities/SecondaryIndexTest.java |3 +- .../cql3/validation/operations/DeleteTest.java | 10 +- .../SelectMultiColumnRelationTest.java | 54 +- .../SelectSingleColumnRelationTest.java | 51 +- .../cql3/validation/operations/SelectTest.java | 1063 +- .../cql3/validation/operations/UpdateTest.java |8 +- .../apache/cassandra/index/CustomIndexTest.java |4 +- .../index/internal/CassandraIndexTest.java | 34 +- 15 files changed, 1199 insertions(+), 146 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/CHANGES.txt -- diff --cc CHANGES.txt index a6cae21,7204098..4c21d66 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,5 -1,5 +1,6 @@@ -3.0.5 +3.5 +Merged from 3.0: + * Fix filtering on non-primary key columns for queries without index (CASSANDRA-6377) * Fix sstableloader fail when using materialized view (CASSANDRA-11275) Merged from 2.2: * Only log yaml config once, at startup (CASSANDRA-11217) http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java -- diff --cc src/java/org/apache/cassandra/cql3/statements/SelectStatement.java index d3a79d0,51d675b..2f4d468 --- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java +++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java @@@ -702,9 -696,8 +696,7 @@@ public class SelectStatement implement // we want to include static columns and we're done. if (!partition.hasNext()) { - if (!staticRow.isEmpty() - && (!restrictions.hasClusteringColumnsRestriction() || cfm.isStaticCompactTable()) - && !restrictions.hasRegularColumnsRestriction()) -if (!staticRow.isEmpty() && (!restrictions.usesSecondaryIndexing() || cfm.isStaticCompactTable()) -&& !restrictions.hasClusteringColumnsRestriction()) ++if (!staticRow.isEmpty() && (!restrictions.hasClusteringColumnsRestriction() || cfm.isStaticCompactTable())) { result.newRow(protocolVersion); for (ColumnDefinition def : selection.getColumns()) http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/db/filter/RowFilter.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/index/internal/CassandraIndex.java -- diff --cc src/java/org/apache/cassandra/index/internal/CassandraIndex.java index f503e59,74d3f5d..c3e75e0 --- a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java +++ b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java @@@ -5,12 -5,13 +5,11 @@@ import java.util.* import java.util.concurrent.Callable; import java.util.concurrent.Future; import java.util.function.BiFunction; -import java.util.regex.Matcher; --import java.util.regex.Pattern; import java.util.stream.Collectors; import java.util.stream.StreamSupport; import com.google.common.collect.ImmutableSet; - import org.apache.cassandra.index.TargetParser; -import org.apache.commons.lang3.StringUtils; ++ imp
[3/6] cassandra git commit: Merge branch cassandra-2.2 into cassandra-3.0
Merge branch cassandra-2.2 into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e01c6dd3 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e01c6dd3 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e01c6dd3 Branch: refs/heads/cassandra-3.5 Commit: e01c6dd3aae90c9eeb4fce7d8dd18123f02fed48 Parents: 19bccb4 90fd8de Author: Benjamin Lerer Authored: Fri Mar 4 22:07:23 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:07:35 2016 +0100 -- --
[2/6] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families
Fix filtering on non-primary key columns for thrift static column families patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/90fd8dee Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/90fd8dee Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/90fd8dee Branch: refs/heads/cassandra-3.5 Commit: 90fd8deed0d1eaa12906bc80aaf54daf837f3a81 Parents: 0934542 Author: Benjamin Lerer Authored: Fri Mar 4 22:05:13 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:05:13 2016 +0100 -- CHANGES.txt | 2 + .../cassandra/cql3/SingleColumnRelation.java| 4 - .../cql3/restrictions/AbstractRestriction.java | 4 +- .../restrictions/StatementRestrictions.java | 25 +- .../cql3/statements/SelectStatement.java| 8 +- .../db/index/SecondaryIndexManager.java | 43 +- .../entities/FrozenCollectionsTest.java | 4 +- .../validation/entities/SecondaryIndexTest.java | 2 +- .../cql3/validation/entities/UFAuthTest.java| 11 - .../entities/UFIdentificationTest.java | 6 +- .../SelectMultiColumnRelationTest.java | 31 +- .../SelectSingleColumnRelationTest.java | 34 +- .../cql3/validation/operations/SelectTest.java | 829 ++- .../db/index/PerRowSecondaryIndexTest.java | 4 +- 14 files changed, 915 insertions(+), 92 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index db6d79d..5631a28 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,6 @@ 2.2.6 + * Fix filtering on non-primary key columns for thrift static column families + (CASSANDRA-6377) * Only log yaml config once, at startup (CASSANDRA-11217) * Preserve order for preferred SSL cipher suites (CASSANDRA-11164) * Reference leak with parallel repairs on the same table (CASSANDRA-11215) http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java -- diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java index b206631..dbae5f0 100644 --- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java +++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java @@ -196,10 +196,6 @@ public final class SingleColumnRelation extends Relation { ColumnSpecification receiver = columnDef; -checkFalse(columnDef.isCompactValue(), - "Predicates on the non-primary-key column (%s) of a COMPACT table are not yet supported", - columnDef.name); - if (isIN()) { // We only allow IN on the row key and the clustering key so far, never on non-PK columns, and this even if http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java -- diff --git a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java index dac7203..385bfbc 100644 --- a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java +++ b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java @@ -93,8 +93,8 @@ abstract class AbstractRestriction implements Restriction ByteBuffer value) throws InvalidRequestException { -checkNotNull(value, "Unsupported null value for indexed column %s", columnSpec.name); -checkBindValueSet(value, "Unsupported unset value for indexed column %s", columnSpec.name); +checkNotNull(value, "Unsupported null value for column %s", columnSpec.name); +checkBindValueSet(value, "Unsupported unset value for column %s", columnSpec.name); checkFalse(value.remaining() > 0x, "Index expression values may not be larger than 64K"); return value; } http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java -- diff --git a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java index 55c6808..e0cf743 100644 --- a/src/java/org/apache/ca
[4/6] cassandra git commit: Fix filtering on non-primary key columns for queries without index
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java -- diff --git a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java index 8622c98..a7eeeb8 100644 --- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java +++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java @@ -24,6 +24,8 @@ import org.junit.Test; import junit.framework.Assert; import org.apache.cassandra.cql3.UntypedResultSet; +import org.apache.cassandra.cql3.restrictions.StatementRestrictions; +import org.apache.cassandra.utils.ByteBufferUtil; import org.apache.cassandra.cql3.CQLTester; import static org.junit.Assert.assertEquals; @@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue; */ public class SelectTest extends CQLTester { +private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65); + @Test public void testSingleClustering() throws Throwable { @@ -366,7 +370,7 @@ public class SelectTest extends CQLTester } @Test -public void testSetContains() throws Throwable +public void testSetContainsWithIndex() throws Throwable { createTable("CREATE TABLE %s (account text, id int, categories set, PRIMARY KEY (account, id))"); createIndex("CREATE INDEX ON %s(categories)"); @@ -387,19 +391,19 @@ public class SelectTest extends CQLTester row("test", 5, set("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", "notPresent")); } @Test -public void testListContains() throws Throwable +public void testListContainsWithIndex() throws Throwable { createTable("CREATE TABLE %s (account text, id int, categories list, PRIMARY KEY (account, id))"); createIndex("CREATE INDEX ON %s(categories)"); @@ -420,13 +424,13 @@ public class SelectTest extends CQLTester row("test", 5, list("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ?", "test", 5, "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", @@ -434,7 +438,7 @@ public class SelectTest extends CQLTester } @Test -public void testListContainsWithFiltering() throws Throwable +public void testListContainsWithIndexAndFiltering() throws Throwable { createTable("CREATE TABLE %s (e int PRIMARY KEY, f list, s int)"); createIndex("CREATE INDEX ON %s(f)"); @@ -452,7 +456,7 @@ public class SelectTest extends CQLTester
[5/6] cassandra git commit: Fix filtering on non-primary key columns for queries without index
Fix filtering on non-primary key columns for queries without index patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9c3855b5 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9c3855b5 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9c3855b5 Branch: refs/heads/cassandra-3.5 Commit: 9c3855b5fd83b9fa9ffb2e5495e43cbea9855dee Parents: e01c6dd Author: Benjamin Lerer Authored: Fri Mar 4 22:09:54 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:09:54 2016 +0100 -- CHANGES.txt |1 + .../cassandra/cql3/SingleColumnRelation.java|4 - .../restrictions/StatementRestrictions.java |8 +- .../cql3/statements/SelectStatement.java| 11 +- .../apache/cassandra/db/filter/RowFilter.java | 51 +- .../index/internal/CassandraIndex.java | 15 + .../entities/FrozenCollectionsTest.java |3 +- .../validation/entities/SecondaryIndexTest.java |3 +- .../cql3/validation/operations/DeleteTest.java | 10 +- .../SelectMultiColumnRelationTest.java | 54 +- .../SelectSingleColumnRelationTest.java | 51 +- .../cql3/validation/operations/SelectTest.java | 1071 +- .../cql3/validation/operations/UpdateTest.java |8 +- .../apache/cassandra/index/CustomIndexTest.java |4 +- .../index/internal/CassandraIndexTest.java | 34 +- 15 files changed, 1205 insertions(+), 123 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 520e66e..7204098 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.0.5 + * Fix filtering on non-primary key columns for queries without index (CASSANDRA-6377) * Fix sstableloader fail when using materialized view (CASSANDRA-11275) Merged from 2.2: * Only log yaml config once, at startup (CASSANDRA-11217) http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java -- diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java index e2c0b79..05ba42d 100644 --- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java +++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java @@ -227,10 +227,6 @@ public final class SingleColumnRelation extends Relation { ColumnSpecification receiver = columnDef; -checkFalse(!columnDef.isPrimaryKeyColumn() && isDense, - "Predicates on the non-primary-key column (%s) of a COMPACT table are not yet supported", - columnDef.name); - if (isIN()) { // We only allow IN on the row key and the clustering key so far, never on non-PK columns, and this even if http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java -- diff --git a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java index 1c7db4e..797b8e4 100644 --- a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java +++ b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java @@ -50,8 +50,10 @@ import static org.apache.cassandra.cql3.statements.RequestValidations.invalidReq */ public final class StatementRestrictions { -public static final String NO_INDEX_FOUND_MESSAGE = -"No supported secondary index found for the non primary key columns restrictions"; +public static final String REQUIRES_ALLOW_FILTERING_MESSAGE = +"Cannot execute this query as it might involve data filtering and " + +"thus may have unpredictable performance. If you want to execute " + +"this query despite the performance unpredictability, use ALLOW FILTERING"; /** * The type of statement @@ -224,7 +226,7 @@ public final class StatementRestrictions if (hasQueriableIndex) usesSecondaryIndexing = true; else if (!useFiltering) -throw invalidRequest(NO_INDEX_FOUND_MESSAGE); +throw invalidRequest(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE); indexRestrictions.add(nonPrimaryKeyRestrictions); } http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apach
[6/7] cassandra git commit: Merge branch cassandra-3.0 into cassandra-3.5
Merge branch cassandra-3.0 into cassandra-3.5 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8c83c8ed Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8c83c8ed Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8c83c8ed Branch: refs/heads/trunk Commit: 8c83c8edab4f1c23c382bb0ac076cab44d5f4dda Parents: a8dc14d 9c3855b Author: Benjamin Lerer Authored: Fri Mar 4 22:12:33 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:13:35 2016 +0100 -- CHANGES.txt |1 + .../cassandra/cql3/SingleColumnRelation.java|4 - .../restrictions/StatementRestrictions.java | 25 +- .../cql3/statements/SelectStatement.java| 12 +- .../apache/cassandra/db/filter/RowFilter.java | 50 +- .../index/internal/CassandraIndex.java | 23 +- .../entities/FrozenCollectionsTest.java |3 +- .../validation/entities/SecondaryIndexTest.java |3 +- .../cql3/validation/operations/DeleteTest.java | 10 +- .../SelectMultiColumnRelationTest.java | 54 +- .../SelectSingleColumnRelationTest.java | 51 +- .../cql3/validation/operations/SelectTest.java | 1063 +- .../cql3/validation/operations/UpdateTest.java |8 +- .../apache/cassandra/index/CustomIndexTest.java |4 +- .../index/internal/CassandraIndexTest.java | 34 +- 15 files changed, 1199 insertions(+), 146 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/CHANGES.txt -- diff --cc CHANGES.txt index a6cae21,7204098..4c21d66 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,5 -1,5 +1,6 @@@ -3.0.5 +3.5 +Merged from 3.0: + * Fix filtering on non-primary key columns for queries without index (CASSANDRA-6377) * Fix sstableloader fail when using materialized view (CASSANDRA-11275) Merged from 2.2: * Only log yaml config once, at startup (CASSANDRA-11217) http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java -- diff --cc src/java/org/apache/cassandra/cql3/statements/SelectStatement.java index d3a79d0,51d675b..2f4d468 --- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java +++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java @@@ -702,9 -696,8 +696,7 @@@ public class SelectStatement implement // we want to include static columns and we're done. if (!partition.hasNext()) { - if (!staticRow.isEmpty() - && (!restrictions.hasClusteringColumnsRestriction() || cfm.isStaticCompactTable()) - && !restrictions.hasRegularColumnsRestriction()) -if (!staticRow.isEmpty() && (!restrictions.usesSecondaryIndexing() || cfm.isStaticCompactTable()) -&& !restrictions.hasClusteringColumnsRestriction()) ++if (!staticRow.isEmpty() && (!restrictions.hasClusteringColumnsRestriction() || cfm.isStaticCompactTable())) { result.newRow(protocolVersion); for (ColumnDefinition def : selection.getColumns()) http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/db/filter/RowFilter.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/index/internal/CassandraIndex.java -- diff --cc src/java/org/apache/cassandra/index/internal/CassandraIndex.java index f503e59,74d3f5d..c3e75e0 --- a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java +++ b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java @@@ -5,12 -5,13 +5,11 @@@ import java.util.* import java.util.concurrent.Callable; import java.util.concurrent.Future; import java.util.function.BiFunction; -import java.util.regex.Matcher; --import java.util.regex.Pattern; import java.util.stream.Collectors; import java.util.stream.StreamSupport; import com.google.common.collect.ImmutableSet; - import org.apache.cassandra.index.TargetParser; -import org.apache.commons.lang3.StringUtils; ++ import org.
[7/7] cassandra git commit: Merge branch cassandra-3.5 into trunk
Merge branch cassandra-3.5 into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6e69c759 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6e69c759 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6e69c759 Branch: refs/heads/trunk Commit: 6e69c75900f3640195130085ad69daa1659184eb Parents: 980e476 8c83c8e Author: Benjamin Lerer Authored: Fri Mar 4 22:15:17 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:15:29 2016 +0100 -- CHANGES.txt |1 + .../cassandra/cql3/SingleColumnRelation.java|4 - .../restrictions/StatementRestrictions.java | 25 +- .../cql3/statements/SelectStatement.java| 12 +- .../apache/cassandra/db/filter/RowFilter.java | 50 +- .../index/internal/CassandraIndex.java | 23 +- .../entities/FrozenCollectionsTest.java |3 +- .../validation/entities/SecondaryIndexTest.java |3 +- .../cql3/validation/operations/DeleteTest.java | 10 +- .../SelectMultiColumnRelationTest.java | 54 +- .../SelectSingleColumnRelationTest.java | 51 +- .../cql3/validation/operations/SelectTest.java | 1063 +- .../cql3/validation/operations/UpdateTest.java |8 +- .../apache/cassandra/index/CustomIndexTest.java |4 +- .../index/internal/CassandraIndexTest.java | 34 +- 15 files changed, 1199 insertions(+), 146 deletions(-) --
[3/7] cassandra git commit: Merge branch cassandra-2.2 into cassandra-3.0
Merge branch cassandra-2.2 into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e01c6dd3 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e01c6dd3 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e01c6dd3 Branch: refs/heads/trunk Commit: e01c6dd3aae90c9eeb4fce7d8dd18123f02fed48 Parents: 19bccb4 90fd8de Author: Benjamin Lerer Authored: Fri Mar 4 22:07:23 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:07:35 2016 +0100 -- --
[2/7] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families
Fix filtering on non-primary key columns for thrift static column families patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/90fd8dee Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/90fd8dee Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/90fd8dee Branch: refs/heads/trunk Commit: 90fd8deed0d1eaa12906bc80aaf54daf837f3a81 Parents: 0934542 Author: Benjamin Lerer Authored: Fri Mar 4 22:05:13 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:05:13 2016 +0100 -- CHANGES.txt | 2 + .../cassandra/cql3/SingleColumnRelation.java| 4 - .../cql3/restrictions/AbstractRestriction.java | 4 +- .../restrictions/StatementRestrictions.java | 25 +- .../cql3/statements/SelectStatement.java| 8 +- .../db/index/SecondaryIndexManager.java | 43 +- .../entities/FrozenCollectionsTest.java | 4 +- .../validation/entities/SecondaryIndexTest.java | 2 +- .../cql3/validation/entities/UFAuthTest.java| 11 - .../entities/UFIdentificationTest.java | 6 +- .../SelectMultiColumnRelationTest.java | 31 +- .../SelectSingleColumnRelationTest.java | 34 +- .../cql3/validation/operations/SelectTest.java | 829 ++- .../db/index/PerRowSecondaryIndexTest.java | 4 +- 14 files changed, 915 insertions(+), 92 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index db6d79d..5631a28 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,6 @@ 2.2.6 + * Fix filtering on non-primary key columns for thrift static column families + (CASSANDRA-6377) * Only log yaml config once, at startup (CASSANDRA-11217) * Preserve order for preferred SSL cipher suites (CASSANDRA-11164) * Reference leak with parallel repairs on the same table (CASSANDRA-11215) http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java -- diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java index b206631..dbae5f0 100644 --- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java +++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java @@ -196,10 +196,6 @@ public final class SingleColumnRelation extends Relation { ColumnSpecification receiver = columnDef; -checkFalse(columnDef.isCompactValue(), - "Predicates on the non-primary-key column (%s) of a COMPACT table are not yet supported", - columnDef.name); - if (isIN()) { // We only allow IN on the row key and the clustering key so far, never on non-PK columns, and this even if http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java -- diff --git a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java index dac7203..385bfbc 100644 --- a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java +++ b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java @@ -93,8 +93,8 @@ abstract class AbstractRestriction implements Restriction ByteBuffer value) throws InvalidRequestException { -checkNotNull(value, "Unsupported null value for indexed column %s", columnSpec.name); -checkBindValueSet(value, "Unsupported unset value for indexed column %s", columnSpec.name); +checkNotNull(value, "Unsupported null value for column %s", columnSpec.name); +checkBindValueSet(value, "Unsupported unset value for column %s", columnSpec.name); checkFalse(value.remaining() > 0x, "Index expression values may not be larger than 64K"); return value; } http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java -- diff --git a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java index 55c6808..e0cf743 100644 --- a/src/java/org/apache/cassandra/
[4/7] cassandra git commit: Fix filtering on non-primary key columns for queries without index
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java -- diff --git a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java index 8622c98..a7eeeb8 100644 --- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java +++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java @@ -24,6 +24,8 @@ import org.junit.Test; import junit.framework.Assert; import org.apache.cassandra.cql3.UntypedResultSet; +import org.apache.cassandra.cql3.restrictions.StatementRestrictions; +import org.apache.cassandra.utils.ByteBufferUtil; import org.apache.cassandra.cql3.CQLTester; import static org.junit.Assert.assertEquals; @@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue; */ public class SelectTest extends CQLTester { +private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65); + @Test public void testSingleClustering() throws Throwable { @@ -366,7 +370,7 @@ public class SelectTest extends CQLTester } @Test -public void testSetContains() throws Throwable +public void testSetContainsWithIndex() throws Throwable { createTable("CREATE TABLE %s (account text, id int, categories set, PRIMARY KEY (account, id))"); createIndex("CREATE INDEX ON %s(categories)"); @@ -387,19 +391,19 @@ public class SelectTest extends CQLTester row("test", 5, set("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", "notPresent")); } @Test -public void testListContains() throws Throwable +public void testListContainsWithIndex() throws Throwable { createTable("CREATE TABLE %s (account text, id int, categories list, PRIMARY KEY (account, id))"); createIndex("CREATE INDEX ON %s(categories)"); @@ -420,13 +424,13 @@ public class SelectTest extends CQLTester row("test", 5, list("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ?", "test", 5, "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", @@ -434,7 +438,7 @@ public class SelectTest extends CQLTester } @Test -public void testListContainsWithFiltering() throws Throwable +public void testListContainsWithIndexAndFiltering() throws Throwable { createTable("CREATE TABLE %s (e int PRIMARY KEY, f list, s int)"); createIndex("CREATE INDEX ON %s(f)"); @@ -452,7 +456,7 @@ public class SelectTest extends CQLTester
[1/7] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families
Repository: cassandra Updated Branches: refs/heads/trunk 980e476bd -> 6e69c7590 http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java -- diff --git a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java index 506bdaf..d8cd3c3 100644 --- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java +++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java @@ -24,6 +24,8 @@ import org.junit.Test; import junit.framework.Assert; import org.apache.cassandra.cql3.UntypedResultSet; +import org.apache.cassandra.cql3.restrictions.StatementRestrictions; +import org.apache.cassandra.utils.ByteBufferUtil; import org.apache.cassandra.cql3.CQLTester; import static org.junit.Assert.assertEquals; @@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue; */ public class SelectTest extends CQLTester { +private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65); + @Test public void testSingleClustering() throws Throwable { @@ -387,13 +391,13 @@ public class SelectTest extends CQLTester row("test", 5, set("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", "notPresent")); } @@ -420,13 +424,13 @@ public class SelectTest extends CQLTester row("test", 5, list("lmn")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE, "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ?", "test", 5, "lmn", "notPresent"); assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", @@ -472,19 +476,19 @@ public class SelectTest extends CQLTester row("test", 5, map("lmn", "foo")) ); -assertInvalidMessage("Unsupported null value for indexed column categories", +assertInvalidMessage("Unsupported null value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS KEY ?", "test", 5, null); -assertInvalidMessage("Unsupported unset value for indexed column categories", +assertInvalidMessage("Unsupported unset value for column categories", "SELECT * FROM %s WHERE account = ? AND id = ? AND categories CONTAINS KEY ?", "test", 5, unset()); -assertInvalidMessage("Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING", + assertInvalidMessage(Statem
[5/7] cassandra git commit: Fix filtering on non-primary key columns for queries without index
Fix filtering on non-primary key columns for queries without index patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9c3855b5 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9c3855b5 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9c3855b5 Branch: refs/heads/trunk Commit: 9c3855b5fd83b9fa9ffb2e5495e43cbea9855dee Parents: e01c6dd Author: Benjamin Lerer Authored: Fri Mar 4 22:09:54 2016 +0100 Committer: Benjamin Lerer Committed: Fri Mar 4 22:09:54 2016 +0100 -- CHANGES.txt |1 + .../cassandra/cql3/SingleColumnRelation.java|4 - .../restrictions/StatementRestrictions.java |8 +- .../cql3/statements/SelectStatement.java| 11 +- .../apache/cassandra/db/filter/RowFilter.java | 51 +- .../index/internal/CassandraIndex.java | 15 + .../entities/FrozenCollectionsTest.java |3 +- .../validation/entities/SecondaryIndexTest.java |3 +- .../cql3/validation/operations/DeleteTest.java | 10 +- .../SelectMultiColumnRelationTest.java | 54 +- .../SelectSingleColumnRelationTest.java | 51 +- .../cql3/validation/operations/SelectTest.java | 1071 +- .../cql3/validation/operations/UpdateTest.java |8 +- .../apache/cassandra/index/CustomIndexTest.java |4 +- .../index/internal/CassandraIndexTest.java | 34 +- 15 files changed, 1205 insertions(+), 123 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 520e66e..7204098 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.0.5 + * Fix filtering on non-primary key columns for queries without index (CASSANDRA-6377) * Fix sstableloader fail when using materialized view (CASSANDRA-11275) Merged from 2.2: * Only log yaml config once, at startup (CASSANDRA-11217) http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java -- diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java index e2c0b79..05ba42d 100644 --- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java +++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java @@ -227,10 +227,6 @@ public final class SingleColumnRelation extends Relation { ColumnSpecification receiver = columnDef; -checkFalse(!columnDef.isPrimaryKeyColumn() && isDense, - "Predicates on the non-primary-key column (%s) of a COMPACT table are not yet supported", - columnDef.name); - if (isIN()) { // We only allow IN on the row key and the clustering key so far, never on non-PK columns, and this even if http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java -- diff --git a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java index 1c7db4e..797b8e4 100644 --- a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java +++ b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java @@ -50,8 +50,10 @@ import static org.apache.cassandra.cql3.statements.RequestValidations.invalidReq */ public final class StatementRestrictions { -public static final String NO_INDEX_FOUND_MESSAGE = -"No supported secondary index found for the non primary key columns restrictions"; +public static final String REQUIRES_ALLOW_FILTERING_MESSAGE = +"Cannot execute this query as it might involve data filtering and " + +"thus may have unpredictable performance. If you want to execute " + +"this query despite the performance unpredictability, use ALLOW FILTERING"; /** * The type of statement @@ -224,7 +226,7 @@ public final class StatementRestrictions if (hasQueriableIndex) usesSecondaryIndexing = true; else if (!useFiltering) -throw invalidRequest(NO_INDEX_FOUND_MESSAGE); +throw invalidRequest(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE); indexRestrictions.add(nonPrimaryKeyRestrictions); } http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassan
[jira] [Updated] (CASSANDRA-6377) ALLOW FILTERING should allow seq scan filtering
[ https://issues.apache.org/jira/browse/CASSANDRA-6377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-6377: -- Resolution: Fixed Fix Version/s: (was: 3.0.x) (was: 3.x) 3.0.5 3.5 2.2.6 Status: Resolved (was: Patch Available) Committed into 2.2 at 90fd8deed0d1eaa12906bc80aaf54daf837f3a81 Committed into 3.0 at 9c3855b5fd83b9fa9ffb2e5495e43cbea9855dee and merged into 3.5 and trunk > ALLOW FILTERING should allow seq scan filtering > --- > > Key: CASSANDRA-6377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6377 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Jonathan Ellis >Assignee: Benjamin Lerer > Labels: cql > Fix For: 2.2.6, 3.5, 3.0.5 > > > CREATE TABLE emp_table2 ( > empID int PRIMARY KEY, > firstname text, > lastname text, > b_mon text, > b_day text, > b_yr text, > ); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (100,'jane','doe','oct','31','1980'); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (101,'john','smith','jan','01','1981'); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (102,'mary','jones','apr','15','1982'); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (103,'tim','best','oct','25','1982'); > > SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2 > WHERE b_mon='oct' ALLOW FILTERING; > Bad Request: No indexed columns present in by-columns clause with Equal > operator -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11278) dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test and tracing_unknown_impl_test
[ https://issues.apache.org/jira/browse/CASSANDRA-11278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russ Hatch updated CASSANDRA-11278: --- Assignee: Jim Witschey (was: DS Test Eng) > dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test > and tracing_unknown_impl_test > > > Key: CASSANDRA-11278 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11278 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: Jim Witschey > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/174/testReport/cql_tracing_test/TestCqlTracing/tracing_default_impl_test > Failed on CassCI build cassandra-3.0_novnode_dtest #174 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11278) dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test and tracing_unknown_impl_test
[ https://issues.apache.org/jira/browse/CASSANDRA-11278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180591#comment-15180591 ] Russ Hatch commented on CASSANDRA-11278: https://github.com/riptano/cassandra-dtest/pull/837 > dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test > and tracing_unknown_impl_test > > > Key: CASSANDRA-11278 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11278 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: Jim Witschey > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/174/testReport/cql_tracing_test/TestCqlTracing/tracing_default_impl_test > Failed on CassCI build cassandra-3.0_novnode_dtest #174 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11278) dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test and tracing_unknown_impl_test
[ https://issues.apache.org/jira/browse/CASSANDRA-11278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180596#comment-15180596 ] Russ Hatch commented on CASSANDRA-11278: >From talking with [~tjake] it sounds like we needed to skip these tests using >since(3.4), which I've done in the pr above. Somewhat related, looks like the dtest method post_cassandra_10392 might need a little update too, but since should suffice for now. > dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test > and tracing_unknown_impl_test > > > Key: CASSANDRA-11278 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11278 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: Jim Witschey > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/174/testReport/cql_tracing_test/TestCqlTracing/tracing_default_impl_test > Failed on CassCI build cassandra-3.0_novnode_dtest #174 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11307) Inappropriate WARN log message for commit log sync delay when using commitlog_sync: batch
Gary Ogasawara created CASSANDRA-11307: -- Summary: Inappropriate WARN log message for commit log sync delay when using commitlog_sync: batch Key: CASSANDRA-11307 URL: https://issues.apache.org/jira/browse/CASSANDRA-11307 Project: Cassandra Issue Type: Bug Components: Core Environment: Linux Reporter: Gary Ogasawara Priority: Minor In v2.1.11 when using configuration commitlog_sync: batch commitlog_sync_batch_window_in_ms: 2 will frequently get this WARN log though there is not a real problem. WARN [COMMIT-LOG-WRITER] 2016-03-03 00:40:11,646 AbstractCommitLogService.java:105 - Out of 142412 commit log syncs over the past 300s with average duration of 0.00ms, 35 have exceeded the configured commit interval by an average of 3.66ms WARN [COMMIT-LOG-WRITER] 2016-03-03 00:45:11,755 AbstractCommitLogService.java:105 - Out of 104605 commit log syncs over the past 300s with average duration of 1.74ms, 18314 have exceeded the configured commit interval by an average of 6.33ms Looks like BatchCommitLogService sets AbstractCommitLogService() pollIntervalMillis to the configured commitlog_sync_batch_window_in_ms. Since CASSANDRA-9504, this is by default set to 2 which causes this WARN message to be triggered unnecessarily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10805) Additional Compaction Logging
[ https://issues.apache.org/jira/browse/CASSANDRA-10805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180621#comment-15180621 ] Carl Yeksigian commented on CASSANDRA-10805: I've pushed a new version of this branch which is updated for the CASSANDRA-6696 changes, and outputs JSON objects. I haven't looked at how to use just the parts of logback that we would want to yet, but if the current approach looks OK except for reimplementing the log rolling, I'll take a look at it early next week. > Additional Compaction Logging > - > > Key: CASSANDRA-10805 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10805 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Observability >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian >Priority: Minor > > Currently, viewing the results of past compactions requires parsing the log > and looking at the compaction history system table, which doesn't have > information about, for example, flushed sstables not previously compacted. > This is a proposal to extend the information captured for compaction. > Initially, this would be done through a JMX call, but if it proves to be > useful and not much overhead, it might be a feature that could be enabled for > the compaction strategy all the time. > Initial log information would include: > - The compaction strategy type controlling each column family > - The set of sstables included in each compaction strategy > - Information about flushes and compactions, including times and all involved > sstables > - Information about sstables, including generation, size, and tokens > - Any additional metadata the strategy wishes to add to a compaction or an > sstable, like the level of an sstable or the type of compaction being > performed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10689) java.lang.OutOfMemoryError: Direct buffer memory
[ https://issues.apache.org/jira/browse/CASSANDRA-10689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180691#comment-15180691 ] Digant Modha commented on CASSANDRA-10689: -- I also have a similar issue: ava.lang.OutOfMemoryError: Direct buffer memory at java.nio.Bits.reserveMemory(Bits.java:658) ~[na:1.8.0_60] at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) ~[na:1.8.0_60] at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) ~[na:1.8.0_60] at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:580) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:456) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.handler.ssl.SslHandler.flush(SslHandler.java:432) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at org.apache.cassandra.transport.Message$Dispatcher$Flusher.run(Message.java:389) ~[apache-cassandra-2.1.12.jar:2.1.12] at io.netty.util.concurrent.PromiseTask$RunnableAdapter.call(PromiseTask.java:38) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:123) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:380) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:268) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60] > java.lang.OutOfMemoryError: Direct buffer memory > > > Key: CASSANDRA-10689 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10689 > Project: Cassandra > Issue Type: Bug >Reporter: mlowicki > > {code} > ERROR [SharedPool-Worker-63] 2015-11-11 17:53:16,161 > JVMStabilityInspector.java:117 - JVM state determined to be unstable. > Exiting forcefully due to: > java.lang.OutOfMemoryError: Direct buffer memory > at java.nio.Bits.reserveMemory(Bits.java:658) ~[na:1.7.0_80] > at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) > ~[na:1.7.0_80] > at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306) > ~[na:1.7.0_80] > at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:174) > ~[na:1.7.0_80] > at sun.nio.ch.IOUtil.read(IOUtil.java:195) ~[na:1.7.0_80] > at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:149) > ~[na:1.7.0_80] > at > org.apache.cassandra.io.compress.CompressedRandomAccessReader.decompressChunk(CompressedRandomAccessReader.java:104) > ~[apache-cassandra-2.1.11.jar:2.1.11] > at > org.apache.cassandra.io.compress.CompressedRandomAccessReader.reBuffer(CompressedRandomAccessReader.java:81) > ~[apache-cassandra-2.1.11.jar:2.1.11] >
[jira] [Comment Edited] (CASSANDRA-10689) java.lang.OutOfMemoryError: Direct buffer memory
[ https://issues.apache.org/jira/browse/CASSANDRA-10689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180691#comment-15180691 ] Digant Modha edited comment on CASSANDRA-10689 at 3/4/16 10:59 PM: --- I also have a similar issue: Top shows process is using 19g memory. The memory usage grows until node dies. It is started with -Xmx8g -Xms8g -Xmn2g. java.lang.OutOfMemoryError: Direct buffer memory at java.nio.Bits.reserveMemory(Bits.java:658) ~[na:1.8.0_60] at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) ~[na:1.8.0_60] at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) ~[na:1.8.0_60] at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:580) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:456) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.handler.ssl.SslHandler.flush(SslHandler.java:432) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at org.apache.cassandra.transport.Message$Dispatcher$Flusher.run(Message.java:389) ~[apache-cassandra-2.1.12.jar:2.1.12] at io.netty.util.concurrent.PromiseTask$RunnableAdapter.call(PromiseTask.java:38) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:123) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:380) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:268) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60] was (Author: dmodha): I also have a similar issue: ava.lang.OutOfMemoryError: Direct buffer memory at java.nio.Bits.reserveMemory(Bits.java:658) ~[na:1.8.0_60] at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) ~[na:1.8.0_60] at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) ~[na:1.8.0_60] at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:580) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:456) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.handler.ssl.SslHandler.flush(SslHandler.java:432) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invo
[jira] [Commented] (CASSANDRA-10726) Read repair inserts should not be blocking
[ https://issues.apache.org/jira/browse/CASSANDRA-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15181335#comment-15181335 ] Richard Low commented on CASSANDRA-10726: - What do you think [~jbellis] [~slebresne]? > Read repair inserts should not be blocking > -- > > Key: CASSANDRA-10726 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10726 > Project: Cassandra > Issue Type: Improvement > Components: Coordination >Reporter: Richard Low > > Today, if there’s a digest mismatch in a foreground read repair, the insert > to update out of date replicas is blocking. This means, if it fails, the read > fails with a timeout. If a node is dropping writes (maybe it is overloaded or > the mutation stage is backed up for some other reason), all reads to a > replica set could fail. Further, replicas dropping writes get more out of > sync so will require more read repair. > The comment on the code for why the writes are blocking is: > {code} > // wait for the repair writes to be acknowledged, to minimize impact on any > replica that's > // behind on writes in case the out-of-sync row is read multiple times in > quick succession > {code} > but the bad side effect is that reads timeout. Either the writes should not > be blocking or we should return success for the read even if the write times > out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10726) Read repair inserts should not be blocking
[ https://issues.apache.org/jira/browse/CASSANDRA-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15181364#comment-15181364 ] Jonathan Ellis commented on CASSANDRA-10726: Yes. And if two of the nodes agree on the most recent value then we don't need to block on the third being updated. > Read repair inserts should not be blocking > -- > > Key: CASSANDRA-10726 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10726 > Project: Cassandra > Issue Type: Improvement > Components: Coordination >Reporter: Richard Low > > Today, if there’s a digest mismatch in a foreground read repair, the insert > to update out of date replicas is blocking. This means, if it fails, the read > fails with a timeout. If a node is dropping writes (maybe it is overloaded or > the mutation stage is backed up for some other reason), all reads to a > replica set could fail. Further, replicas dropping writes get more out of > sync so will require more read repair. > The comment on the code for why the writes are blocking is: > {code} > // wait for the repair writes to be acknowledged, to minimize impact on any > replica that's > // behind on writes in case the out-of-sync row is read multiple times in > quick succession > {code} > but the bad side effect is that reads timeout. Either the writes should not > be blocking or we should return success for the read even if the write times > out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10726) Read repair inserts should not be blocking
[ https://issues.apache.org/jira/browse/CASSANDRA-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15181364#comment-15181364 ] Jonathan Ellis edited comment on CASSANDRA-10726 at 3/5/16 12:40 AM: - Yes. And if two of the nodes agree on the most recent value then we don't need to block on the third being updated since our monotonicity of future quorum reads is already assured. was (Author: jbellis): Yes. And if two of the nodes agree on the most recent value then we don't need to block on the third being updated. > Read repair inserts should not be blocking > -- > > Key: CASSANDRA-10726 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10726 > Project: Cassandra > Issue Type: Improvement > Components: Coordination >Reporter: Richard Low > > Today, if there’s a digest mismatch in a foreground read repair, the insert > to update out of date replicas is blocking. This means, if it fails, the read > fails with a timeout. If a node is dropping writes (maybe it is overloaded or > the mutation stage is backed up for some other reason), all reads to a > replica set could fail. Further, replicas dropping writes get more out of > sync so will require more read repair. > The comment on the code for why the writes are blocking is: > {code} > // wait for the repair writes to be acknowledged, to minimize impact on any > replica that's > // behind on writes in case the out-of-sync row is read multiple times in > quick succession > {code} > but the bad side effect is that reads timeout. Either the writes should not > be blocking or we should return success for the read even if the write times > out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10990) Support streaming of older version sstables in 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15181464#comment-15181464 ] Paulo Motta commented on CASSANDRA-10990: - Updated branch with reworked {{RewindableDataInputStreamPlus}}, now treating the spill file as circular buffer with max size. Now required space for spill buffer file of legacy {{StreamDeserializer}} is {{max(sstableSize, MAX_INT)}}, capping the max required space for streaming older version sstables on ~2GB. I also updated documentation and tests. WDYT [~yukim]? Besides that, I added a new [dtest|https://github.com/pauloricardomg/cassandra-dtest/commit/b59ea329a5b9302372c57956f7015111fd47a4ae] for testing repair of older version sstables on 3.0+, and it seems to work. Now we have the following dtests: * [bootstrap dtests|https://github.com/pauloricardomg/cassandra-dtest/blob/10990/upgrade_8099_test.py#L340] * [sstable loader dtests|https://github.com/pauloricardomg/cassandra-dtest/blob/10990/sstable_generation_loading_test.py#L181] * [repair dtests|https://github.com/pauloricardomg/cassandra-dtest/commit/b59ea329a5b9302372c57956f7015111fd47a4ae] For simplicity, I opted for writing the old streamed sstables in the new format without {{EncodingStats}} (since there is no {{SerializationHeader}} available), what may make these sstables less optimized in terms of storage space from what I understood. Do you think we should construct these stats when receiving the sstable or not bother [~slebresne] ? Also, do you recall of any other edge case we should watch here? Thanks! > Support streaming of older version sstables in 3.0 > -- > > Key: CASSANDRA-10990 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10990 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Jeremy Hanna >Assignee: Paulo Motta > > In 2.0 we introduced support for streaming older versioned sstables > (CASSANDRA-5772). In 3.0, because of the rewrite of the storage layer, this > became no longer supported. So currently, while 3.0 can read sstables in the > 2.1/2.2 format, it cannot stream the older versioned sstables. We should do > some work to make this still possible to be consistent with what > CASSANDRA-5772 provided. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10990) Support streaming of older version sstables in 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15181464#comment-15181464 ] Paulo Motta edited comment on CASSANDRA-10990 at 3/5/16 2:52 AM: - Updated branch with reworked {{RewindableDataInputStreamPlus}}, now treating the spill file as circular buffer with max size. Now required space for spill buffer file of legacy {{StreamDeserializer}} is {{max(sstableSize, MAX_INT)}}, capping the max required space (and max partition size) for streaming legacy/compact sstables on ~2GB. I also updated documentation and tests. WDYT [~yukim]? Besides that, I added a new [dtest|https://github.com/pauloricardomg/cassandra-dtest/commit/b59ea329a5b9302372c57956f7015111fd47a4ae] for testing repair of older version sstables on 3.0+, and it seems to work. Now we have the following dtests: * [bootstrap dtests|https://github.com/pauloricardomg/cassandra-dtest/blob/10990/upgrade_8099_test.py#L340] * [sstable loader dtests|https://github.com/pauloricardomg/cassandra-dtest/blob/10990/sstable_generation_loading_test.py#L181] * [repair dtests|https://github.com/pauloricardomg/cassandra-dtest/commit/b59ea329a5b9302372c57956f7015111fd47a4ae] For simplicity, I opted for writing the old streamed sstables in the new format without {{EncodingStats}} (since there is no {{SerializationHeader}} available), what may make these sstables less optimized in terms of storage space from what I understood. Do you think we should construct these stats when receiving the sstable or not bother [~slebresne] ? Also, do you recall of any other edge case we should watch here? Thanks! was (Author: pauloricardomg): Updated branch with reworked {{RewindableDataInputStreamPlus}}, now treating the spill file as circular buffer with max size. Now required space for spill buffer file of legacy {{StreamDeserializer}} is {{max(sstableSize, MAX_INT)}}, capping the max required space for streaming older version sstables on ~2GB. I also updated documentation and tests. WDYT [~yukim]? Besides that, I added a new [dtest|https://github.com/pauloricardomg/cassandra-dtest/commit/b59ea329a5b9302372c57956f7015111fd47a4ae] for testing repair of older version sstables on 3.0+, and it seems to work. Now we have the following dtests: * [bootstrap dtests|https://github.com/pauloricardomg/cassandra-dtest/blob/10990/upgrade_8099_test.py#L340] * [sstable loader dtests|https://github.com/pauloricardomg/cassandra-dtest/blob/10990/sstable_generation_loading_test.py#L181] * [repair dtests|https://github.com/pauloricardomg/cassandra-dtest/commit/b59ea329a5b9302372c57956f7015111fd47a4ae] For simplicity, I opted for writing the old streamed sstables in the new format without {{EncodingStats}} (since there is no {{SerializationHeader}} available), what may make these sstables less optimized in terms of storage space from what I understood. Do you think we should construct these stats when receiving the sstable or not bother [~slebresne] ? Also, do you recall of any other edge case we should watch here? Thanks! > Support streaming of older version sstables in 3.0 > -- > > Key: CASSANDRA-10990 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10990 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Jeremy Hanna >Assignee: Paulo Motta > > In 2.0 we introduced support for streaming older versioned sstables > (CASSANDRA-5772). In 3.0, because of the rewrite of the storage layer, this > became no longer supported. So currently, while 3.0 can read sstables in the > 2.1/2.2 format, it cannot stream the older versioned sstables. We should do > some work to make this still possible to be consistent with what > CASSANDRA-5772 provided. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6377) ALLOW FILTERING should allow seq scan filtering
[ https://issues.apache.org/jira/browse/CASSANDRA-6377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15181491#comment-15181491 ] Srini commented on CASSANDRA-6377: -- Is this ready to test? Which version we should use? Our use case is that during the read we have the primary key and only few columns of the cluster key (not in the sequence). We would like to filter the rows in the partition that satisfy the primary key and partial columns of the cluster key. > ALLOW FILTERING should allow seq scan filtering > --- > > Key: CASSANDRA-6377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6377 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Jonathan Ellis >Assignee: Benjamin Lerer > Labels: cql > Fix For: 2.2.6, 3.5, 3.0.5 > > > CREATE TABLE emp_table2 ( > empID int PRIMARY KEY, > firstname text, > lastname text, > b_mon text, > b_day text, > b_yr text, > ); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (100,'jane','doe','oct','31','1980'); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (101,'john','smith','jan','01','1981'); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (102,'mary','jones','apr','15','1982'); > INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) >VALUES (103,'tim','best','oct','25','1982'); > > SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2 > WHERE b_mon='oct' ALLOW FILTERING; > Bad Request: No indexed columns present in by-columns clause with Equal > operator -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11258) Repair scheduling - Resource locking API
[ https://issues.apache.org/jira/browse/CASSANDRA-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15181495#comment-15181495 ] Paulo Motta commented on CASSANDRA-11258: - bq. However, if we want to visualize all data center locks to the user, it would be more complex to do so. That's a good point, we might want to view remote locks in the future so I'm not sure {{LDCRS}} would be a good fit in this case. We could maybe save the remote lock info in the local keyspace but this wouldn't be very different (and probably more complex) than having a global keyspace. And we might also want to introduce global locks in the future, so we would need a global keyspace in addition to the local one. bq. Should we start with SimpleStrategy and a replication of 3 then? Yes, I think we should advance the implementation based on {{SimpleStrategy}} for now and focus on single DC first, and think better about multi-DC support in a separate task (since it may become easier to reason about multi-DC details when we have a full scheduled repair cycle working for a single DC). > Repair scheduling - Resource locking API > > > Key: CASSANDRA-11258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11258 > Project: Cassandra > Issue Type: Sub-task >Reporter: Marcus Olsson >Assignee: Marcus Olsson >Priority: Minor > > Create a resource locking API & implementation that is able to lock a > resource in a specified data center. It should handle priorities to avoid > node starvation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10752) CQL.textile wasn't updated for CASSANDRA-6839
[ https://issues.apache.org/jira/browse/CASSANDRA-10752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan updated CASSANDRA-10752: Fix Version/s: 3.x 3.0.x 2.2.x 2.1.x > CQL.textile wasn't updated for CASSANDRA-6839 > - > > Key: CASSANDRA-10752 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10752 > Project: Cassandra > Issue Type: Bug > Components: Documentation and Website >Reporter: Jeremiah Jordan >Assignee: Tyler Hobbs > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x > > > CQL.textile wasn't updated after CASSANDRA-6839 added inequalities for LWT's. -- This message was sent by Atlassian JIRA (v6.3.4#6332)