[jira] [Created] (CASSANDRA-13198) DROP TABLE throws java.lang.AssertionError
Lan Nguyen created CASSANDRA-13198: -- Summary: DROP TABLE throws java.lang.AssertionError Key: CASSANDRA-13198 URL: https://issues.apache.org/jira/browse/CASSANDRA-13198 Project: Cassandra Issue Type: Bug Components: CQL Environment: ubuntu Reporter: Lan Nguyen Fix For: 3.10 "DROP TABLE" throws ServerError: java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.AssertionError -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13197) +=/-= shortcut syntax bugs/inconsistencies
[ https://issues.apache.org/jira/browse/CASSANDRA-13197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Karunaratne updated CASSANDRA-13197: --- Description: CASSANDRA-12232 introduced (+=/-=) shortcuts for counters and collection types. I ran into some bugs/consistencies. Given the schema: {noformat} CREATE TABLE simplex.collection_table (k int PRIMARY KEY, d_l List, d_s Set, d_m Map, d_t Tuple); {noformat} 1) Using -= on a list column removes all elements that match the value, instead of the first or last occurrence of it. Is this expected? {noformat} Given d_l = [0, 1, 2, 1, 1] UPDATE collection_table SET d_l -= [1] WHERE k=0; yields [0, 2] {noformat} 2) I can't seem to remove a map key/value pair: {noformat} Given d_m = {0: 0, 1: 1} UPDATE collection_table SET d_m -= {1:1} WHERE k=0; yields Invalid map literal for d_m of type frozen> {noformat} However {noformat}UPDATE collection_table SET d_m -= {1} WHERE k=0;{noformat} does work. 3) Tuples are immutable so it make sense that +=/-= doesn't apply. However the error message could be better, now that other collection types are allowed: {noformat} UPDATE collection_table SET d_t += (1) WHERE k=0; yields Invalid operation (d_t = d_t + (1)) for non counter column d_t {noformat} was: CASSANDRA-12232 introduced (+=/-=) shortcuts for counters and collection types. I ran into some bugs/consistencies. Given the schema: {noformat} CREATE TABLE simplex.collection_table (k int PRIMARY KEY, d_l List, d_s Set, d_m Map, d_t Tuple); {noformat} 1) Using -= on a list column removes all elements that match the value, instead of the first or last occurrence of it. Is this expected? {noformat} Given d_l = [0, 1, 2, 1, 1] UPDATE collection_table SET d_l -= [1] WHERE k=0; yields [0, 2] {noformat} 2) I can't seem to remove a map key/value pair: {noformat} Given d_m = {0: 0, 1: 1} UPDATE collection_table SET d_m -= {1:1} WHERE k=0; yields Invalid map literal for d_m of type frozen> {noformat} 3) Tuples are immutable so it make sense that +=/-= doesn't apply. However the error message could be better, now that other collection types are allowed: {noformat} UPDATE collection_table SET d_t += (1) WHERE k=0; yields Invalid operation (d_t = d_t + (1)) for non counter column d_t {noformat} > +=/-= shortcut syntax bugs/inconsistencies > -- > > Key: CASSANDRA-13197 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13197 > Project: Cassandra > Issue Type: Bug >Reporter: Kishan Karunaratne > > CASSANDRA-12232 introduced (+=/-=) shortcuts for counters and collection > types. I ran into some bugs/consistencies. > Given the schema: > {noformat} > CREATE TABLE simplex.collection_table (k int PRIMARY KEY, d_l List, d_s > Set, d_m Map, d_t Tuple); > {noformat} > 1) Using -= on a list column removes all elements that match the value, > instead of the first or last occurrence of it. Is this expected? > {noformat} > Given d_l = [0, 1, 2, 1, 1] > UPDATE collection_table SET d_l -= [1] WHERE k=0; > yields > [0, 2] > {noformat} > 2) I can't seem to remove a map key/value pair: > {noformat} > Given d_m = {0: 0, 1: 1} > UPDATE collection_table SET d_m -= {1:1} WHERE k=0; > yields > Invalid map literal for d_m of type frozen> > {noformat} > However {noformat}UPDATE collection_table SET d_m -= {1} WHERE k=0;{noformat} > does work. > 3) Tuples are immutable so it make sense that +=/-= doesn't apply. However > the error message could be better, now that other collection types are > allowed: > {noformat} > UPDATE collection_table SET d_t += (1) WHERE k=0; > yields > Invalid operation (d_t = d_t + (1)) for non counter column d_t > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13197) +=/-= shortcut syntax bugs/inconsistencies
[ https://issues.apache.org/jira/browse/CASSANDRA-13197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Karunaratne updated CASSANDRA-13197: --- Description: CASSANDRA-12232 introduced (+=/-=) shortcuts for counters and collection types. I ran into some bugs/consistencies. Given the schema: {noformat} CREATE TABLE simplex.collection_table (k int PRIMARY KEY, d_l List, d_s Set, d_m Map, d_t Tuple); {noformat} 1) Using -= on a list column removes all elements that match the value, instead of the first or last occurrence of it. Is this expected? {noformat} Given d_l = [0, 1, 2, 1, 1] UPDATE collection_table SET d_l -= [1] WHERE k=0; yields [0, 2] {noformat} 2) I can't seem to remove a map key/value pair: {noformat} Given d_m = {0: 0, 1: 1} UPDATE collection_table SET d_m -= {1:1} WHERE k=0; yields Invalid map literal for d_m of type frozen> {noformat} 3) Tuples are immutable so it make sense that +=/-= doesn't apply. However the error message could be better, now that other collection types are allowed: {noformat} UPDATE collection_table SET d_t += (1) WHERE k=0; yields Invalid operation (d_t = d_t + (1)) for non counter column d_t {noformat} was: CASSANDRA-12232 introduced (+=/-=) shortcuts for counters and collection types. I ran into some bugs/consistencies. Given the schema: {noformat} CREATE TABLE simplex.collection_table (k int PRIMARY KEY, d_l List, d_s Set, d_m Map, d_t Tuple); {noformat} 1) Using -= on a list column removes all elements that match the value, instead of the first or last occurrence of it. Is this expected? e.g. Given d_l = [0, 1, 2, 1, 1] UPDATE collection_table SET d_l -= [1] WHERE k=0; yields [0, 2] 2) I can't seem to remove a map key/value pair: e.g. Given d_m = {0: 0, 1: 1} UPDATE collection_table SET d_m -= {1:1} WHERE k=0; yields Invalid map literal for d_m of type frozen> 3) Tuples are immutable so it make sense that +=/-= doesn't apply. However the error message could be better, now that other collection types are allowed: UPDATE collection_table SET d_t += (1) WHERE k=0; yields Invalid operation (d_t = d_t + (1)) for non counter column d_t > +=/-= shortcut syntax bugs/inconsistencies > -- > > Key: CASSANDRA-13197 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13197 > Project: Cassandra > Issue Type: Bug >Reporter: Kishan Karunaratne > > CASSANDRA-12232 introduced (+=/-=) shortcuts for counters and collection > types. I ran into some bugs/consistencies. > Given the schema: > {noformat} > CREATE TABLE simplex.collection_table (k int PRIMARY KEY, d_l List, d_s > Set, d_m Map, d_t Tuple); > {noformat} > 1) Using -= on a list column removes all elements that match the value, > instead of the first or last occurrence of it. Is this expected? > {noformat} > Given d_l = [0, 1, 2, 1, 1] > UPDATE collection_table SET d_l -= [1] WHERE k=0; > yields > [0, 2] > {noformat} > 2) I can't seem to remove a map key/value pair: > {noformat} > Given d_m = {0: 0, 1: 1} > UPDATE collection_table SET d_m -= {1:1} WHERE k=0; > yields > Invalid map literal for d_m of type frozen> > {noformat} > 3) Tuples are immutable so it make sense that +=/-= doesn't apply. However > the error message could be better, now that other collection types are > allowed: > {noformat} > UPDATE collection_table SET d_t += (1) WHERE k=0; > yields > Invalid operation (d_t = d_t + (1)) for non counter column d_t > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CASSANDRA-13197) +=/-= shortcut syntax bugs/inconsistencies
Kishan Karunaratne created CASSANDRA-13197: -- Summary: +=/-= shortcut syntax bugs/inconsistencies Key: CASSANDRA-13197 URL: https://issues.apache.org/jira/browse/CASSANDRA-13197 Project: Cassandra Issue Type: Bug Reporter: Kishan Karunaratne CASSANDRA-12232 introduced (+=/-=) shortcuts for counters and collection types. I ran into some bugs/consistencies. Given the schema: {noformat} CREATE TABLE simplex.collection_table (k int PRIMARY KEY, d_l List, d_s Set, d_m Map, d_t Tuple); {noformat} 1) Using -= on a list column removes all elements that match the value, instead of the first or last occurrence of it. Is this expected? e.g. Given d_l = [0, 1, 2, 1, 1] UPDATE collection_table SET d_l -= [1] WHERE k=0; yields [0, 2] 2) I can't seem to remove a map key/value pair: e.g. Given d_m = {0: 0, 1: 1} UPDATE collection_table SET d_m -= {1:1} WHERE k=0; yields Invalid map literal for d_m of type frozen> 3) Tuples are immutable so it make sense that +=/-= doesn't apply. However the error message could be better, now that other collection types are allowed: UPDATE collection_table SET d_t += (1) WHERE k=0; yields Invalid operation (d_t = d_t + (1)) for non counter column d_t -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CASSANDRA-13196) test failure in snitch_test.TestGossipingPropertyFileSnitch.test_prefer_local_reconnect_on_listen_address
Michael Shuler created CASSANDRA-13196: -- Summary: test failure in snitch_test.TestGossipingPropertyFileSnitch.test_prefer_local_reconnect_on_listen_address Key: CASSANDRA-13196 URL: https://issues.apache.org/jira/browse/CASSANDRA-13196 Project: Cassandra Issue Type: Bug Reporter: Michael Shuler Attachments: node1_debug.log, node1_gc.log, node1.log, node2_debug.log, node2_gc.log, node2.log example failure: http://cassci.datastax.com/job/trunk_dtest/1487/testReport/snitch_test/TestGossipingPropertyFileSnitch/test_prefer_local_reconnect_on_listen_address {novnode} Error Message Error from server: code=2200 [Invalid query] message="keyspace keyspace1 does not exist" >> begin captured logging << dtest: DEBUG: cluster ccm directory: /tmp/dtest-k6b0iF dtest: DEBUG: Done setting configuration options: { 'initial_token': None, 'num_tokens': '32', 'phi_convict_threshold': 5, 'range_request_timeout_in_ms': 1, 'read_request_timeout_in_ms': 1, 'request_timeout_in_ms': 1, 'truncate_request_timeout_in_ms': 1, 'write_request_timeout_in_ms': 1} cassandra.policies: INFO: Using datacenter 'dc1' for DCAwareRoundRobinPolicy (via host '127.0.0.1'); if incorrect, please specify a local_dc to the constructor, or limit contact points to local cluster nodes cassandra.cluster: INFO: New Cassandra host discovered - >> end captured logging << - Stacktrace File "/usr/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/home/automaton/cassandra-dtest/snitch_test.py", line 87, in test_prefer_local_reconnect_on_listen_address new_rows = list(session.execute("SELECT * FROM {}".format(stress_table))) File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 1998, in execute return self.execute_async(query, parameters, trace, custom_payload, timeout, execution_profile, paging_state).result() File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 3784, in result raise self._final_exception 'Error from server: code=2200 [Invalid query] message="keyspace keyspace1 does not exist"\n >> begin captured logging << \ndtest: DEBUG: cluster ccm directory: /tmp/dtest-k6b0iF\ndtest: DEBUG: Done setting configuration options:\n{ \'initial_token\': None,\n\'num_tokens\': \'32\',\n \'phi_convict_threshold\': 5,\n\'range_request_timeout_in_ms\': 1,\n \'read_request_timeout_in_ms\': 1,\n\'request_timeout_in_ms\': 1,\n \'truncate_request_timeout_in_ms\': 1,\n \'write_request_timeout_in_ms\': 1}\ncassandra.policies: INFO: Using datacenter \'dc1\' for DCAwareRoundRobinPolicy (via host \'127.0.0.1\'); if incorrect, please specify a local_dc to the constructor, or limit contact points to local cluster nodes\ncassandra.cluster: INFO: New Cassandra host discovered\n- >> end captured logging << -' {novnode} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13188) compaction-stress AssertionError from getMemtableFor()
[ https://issues.apache.org/jira/browse/CASSANDRA-13188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857174#comment-15857174 ] Jay Zhuang commented on CASSANDRA-13188: The problem is because memtable [is not initialized for tool|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L410] [The fix|https://github.com/cooldoger/cassandra/commit/d2ddeb75cbcbdd407aca33f56f4ab59552a13cdf] is attached. [~tjake] would you please review. An alternative fix would be changing [toolInitialization()|https://github.com/apache/cassandra/blob/cassandra-3.11/tools/stress/src/org/apache/cassandra/stress/CompactionStress.java#L77] to [daemonInitialization()|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L128]. (I prefer the first option, as compaction-stress is really a tool, not daemon). > compaction-stress AssertionError from getMemtableFor() > -- > > Key: CASSANDRA-13188 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13188 > Project: Cassandra > Issue Type: Bug > Components: Testing, Tools >Reporter: Jay Zhuang >Assignee: Jay Zhuang > Attachments: 13188-3.11.txt, 13188-3.11-update.txt > > > Exception: > {noformat} > ./compaction-stress compact -d /tmp/compaction -p > https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml > -t 4 > WARN 18:45:04,854 JNA link failure, one or more native method will be > unavailable. > java.lang.AssertionError: [] > at > org.apache.cassandra.db.lifecycle.Tracker.getMemtableFor(Tracker.java:312) > at > org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1315) > at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:618) > at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:462) > at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) > at org.apache.cassandra.db.Mutation.apply(Mutation.java:232) > at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) > at > org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:570) > at > org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:564) > at > org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:356) > at > org.apache.cassandra.schema.SchemaKeyspace.saveSystemKeyspacesSchema(SchemaKeyspace.java:265) > at > org.apache.cassandra.db.SystemKeyspace.finishStartup(SystemKeyspace.java:495) > at > org.apache.cassandra.stress.CompactionStress$Compaction.run(CompactionStress.java:209) > at > org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:349) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13188) compaction-stress AssertionError from getMemtableFor()
[ https://issues.apache.org/jira/browse/CASSANDRA-13188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Zhuang updated CASSANDRA-13188: --- Attachment: 13188-3.11-update.txt > compaction-stress AssertionError from getMemtableFor() > -- > > Key: CASSANDRA-13188 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13188 > Project: Cassandra > Issue Type: Bug > Components: Testing, Tools >Reporter: Jay Zhuang >Assignee: Jay Zhuang > Attachments: 13188-3.11.txt, 13188-3.11-update.txt > > > Exception: > {noformat} > ./compaction-stress compact -d /tmp/compaction -p > https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml > -t 4 > WARN 18:45:04,854 JNA link failure, one or more native method will be > unavailable. > java.lang.AssertionError: [] > at > org.apache.cassandra.db.lifecycle.Tracker.getMemtableFor(Tracker.java:312) > at > org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1315) > at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:618) > at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:462) > at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) > at org.apache.cassandra.db.Mutation.apply(Mutation.java:232) > at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) > at > org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:570) > at > org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:564) > at > org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:356) > at > org.apache.cassandra.schema.SchemaKeyspace.saveSystemKeyspacesSchema(SchemaKeyspace.java:265) > at > org.apache.cassandra.db.SystemKeyspace.finishStartup(SystemKeyspace.java:495) > at > org.apache.cassandra.stress.CompactionStress$Compaction.run(CompactionStress.java:209) > at > org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:349) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CASSANDRA-13183) test failure in compaction_test.TestCompaction_with_*CompactionStrategy.compaction_throughput_test
[ https://issues.apache.org/jira/browse/CASSANDRA-13183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler resolved CASSANDRA-13183. Resolution: Duplicate Thanks. It does look like the last few runs have passed. > test failure in > compaction_test.TestCompaction_with_*CompactionStrategy.compaction_throughput_test > -- > > Key: CASSANDRA-13183 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13183 > Project: Cassandra > Issue Type: Bug >Reporter: Michael Shuler > Labels: dtest, test-failure > Attachments: logs.tar.gz > > > This test failed on both Leveled and DateTiered. > example failures: > http://cassci.datastax.com/job/trunk_novnode_dtest/506/testReport/compaction_test/TestCompaction_with_LeveledCompactionStrategy/compaction_throughput_test > http://cassci.datastax.com/job/trunk_novnode_dtest/506/testReport/compaction_test/TestCompaction_with_DateTieredCompactionStrategy/compaction_throughput_test/ > Leveled: > {noformat} > Error Message > 5.5 not greater than or equal to 6.316 > >> begin captured logging << > dtest: DEBUG: cluster ccm directory: /tmp/dtest-lhjy7D > dtest: DEBUG: Done setting configuration options: > { 'num_tokens': None, > 'phi_convict_threshold': 5, > 'range_request_timeout_in_ms': 1, > 'read_request_timeout_in_ms': 1, > 'request_timeout_in_ms': 1, > 'truncate_request_timeout_in_ms': 1, > 'write_request_timeout_in_ms': 1} > parse: DEBUG: format '{}={avgthroughput:f}{units}/s' -> > '(.+?)=(?P[-+ ]?\\d+\\.\\d+)(?P.+?)/s' > dtest: DEBUG: 6.316 > - >> end captured logging << - > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/compaction_test.py", line 280, in > compaction_throughput_test > self.assertGreaterEqual(float(threshold) + 0.5, float(avgthroughput)) > File "/usr/lib/python2.7/unittest/case.py", line 948, in assertGreaterEqual > self.fail(self._formatMessage(msg, standardMsg)) > File "/usr/lib/python2.7/unittest/case.py", line 410, in fail > raise self.failureException(msg) > "5.5 not greater than or equal to 6.316\n >> begin > captured logging << \ndtest: DEBUG: cluster ccm > directory: /tmp/dtest-lhjy7D\ndtest: DEBUG: Done setting configuration > options:\n{ 'num_tokens': None,\n'phi_convict_threshold': 5,\n > 'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms': > 1,\n'request_timeout_in_ms': 1,\n > 'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms': > 1}\nparse: DEBUG: format '{}={avgthroughput:f}{units}/s' -> > '(.+?)=(?P[-+ ]?d+.d+)(?P.+?)/s'\ndtest: > DEBUG: 6.316\n- >> end captured logging << > -" > {noformat} > DateTiered: > {noformat} > Error Message > 5.5 not greater than or equal to 5.681 > >> begin captured logging << > dtest: DEBUG: cluster ccm directory: /tmp/dtest-FXOwMR > dtest: DEBUG: Done setting configuration options: > { 'num_tokens': None, > 'phi_convict_threshold': 5, > 'range_request_timeout_in_ms': 1, > 'read_request_timeout_in_ms': 1, > 'request_timeout_in_ms': 1, > 'truncate_request_timeout_in_ms': 1, > 'write_request_timeout_in_ms': 1} > parse: DEBUG: format '{}={avgthroughput:f}{units}/s' -> > '(.+?)=(?P[-+ ]?\\d+\\.\\d+)(?P.+?)/s' > dtest: DEBUG: 5.681 > - >> end captured logging << - > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/compaction_test.py", line 280, in > compaction_throughput_test > self.assertGreaterEqual(float(threshold) + 0.5, float(avgthroughput)) > File "/usr/lib/python2.7/unittest/case.py", line 948, in assertGreaterEqual > self.fail(self._formatMessage(msg, standardMsg)) > File "/usr/lib/python2.7/unittest/case.py", line 410, in fail > raise self.failureException(msg) > "5.5 not greater than or equal to 5.681\n >> begin > captured logging << \ndtest: DEBUG: cluster ccm > directory: /tmp/dtest-FXOwMR\ndtest: DEBUG: Done setting configuration > options:\n{ 'num_tokens': None,\n'phi_convict_threshold': 5,\n > 'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms': > 1,\n'request_timeout_in_ms': 1,\n > 'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms': > 1}\nparse: DEBUG: format '{}={avgthroughput:f}{units}/s' ->
[jira] [Commented] (CASSANDRA-13183) test failure in compaction_test.TestCompaction_with_*CompactionStrategy.compaction_throughput_test
[ https://issues.apache.org/jira/browse/CASSANDRA-13183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15856994#comment-15856994 ] Aleksandr Sorokoumov commented on CASSANDRA-13183: -- Hello [~mshuler], I believe that the compaction_throughput_test should be fixed in CASSANDRA-13170. > test failure in > compaction_test.TestCompaction_with_*CompactionStrategy.compaction_throughput_test > -- > > Key: CASSANDRA-13183 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13183 > Project: Cassandra > Issue Type: Bug >Reporter: Michael Shuler > Labels: dtest, test-failure > Attachments: logs.tar.gz > > > This test failed on both Leveled and DateTiered. > example failures: > http://cassci.datastax.com/job/trunk_novnode_dtest/506/testReport/compaction_test/TestCompaction_with_LeveledCompactionStrategy/compaction_throughput_test > http://cassci.datastax.com/job/trunk_novnode_dtest/506/testReport/compaction_test/TestCompaction_with_DateTieredCompactionStrategy/compaction_throughput_test/ > Leveled: > {noformat} > Error Message > 5.5 not greater than or equal to 6.316 > >> begin captured logging << > dtest: DEBUG: cluster ccm directory: /tmp/dtest-lhjy7D > dtest: DEBUG: Done setting configuration options: > { 'num_tokens': None, > 'phi_convict_threshold': 5, > 'range_request_timeout_in_ms': 1, > 'read_request_timeout_in_ms': 1, > 'request_timeout_in_ms': 1, > 'truncate_request_timeout_in_ms': 1, > 'write_request_timeout_in_ms': 1} > parse: DEBUG: format '{}={avgthroughput:f}{units}/s' -> > '(.+?)=(?P[-+ ]?\\d+\\.\\d+)(?P.+?)/s' > dtest: DEBUG: 6.316 > - >> end captured logging << - > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/compaction_test.py", line 280, in > compaction_throughput_test > self.assertGreaterEqual(float(threshold) + 0.5, float(avgthroughput)) > File "/usr/lib/python2.7/unittest/case.py", line 948, in assertGreaterEqual > self.fail(self._formatMessage(msg, standardMsg)) > File "/usr/lib/python2.7/unittest/case.py", line 410, in fail > raise self.failureException(msg) > "5.5 not greater than or equal to 6.316\n >> begin > captured logging << \ndtest: DEBUG: cluster ccm > directory: /tmp/dtest-lhjy7D\ndtest: DEBUG: Done setting configuration > options:\n{ 'num_tokens': None,\n'phi_convict_threshold': 5,\n > 'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms': > 1,\n'request_timeout_in_ms': 1,\n > 'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms': > 1}\nparse: DEBUG: format '{}={avgthroughput:f}{units}/s' -> > '(.+?)=(?P[-+ ]?d+.d+)(?P.+?)/s'\ndtest: > DEBUG: 6.316\n- >> end captured logging << > -" > {noformat} > DateTiered: > {noformat} > Error Message > 5.5 not greater than or equal to 5.681 > >> begin captured logging << > dtest: DEBUG: cluster ccm directory: /tmp/dtest-FXOwMR > dtest: DEBUG: Done setting configuration options: > { 'num_tokens': None, > 'phi_convict_threshold': 5, > 'range_request_timeout_in_ms': 1, > 'read_request_timeout_in_ms': 1, > 'request_timeout_in_ms': 1, > 'truncate_request_timeout_in_ms': 1, > 'write_request_timeout_in_ms': 1} > parse: DEBUG: format '{}={avgthroughput:f}{units}/s' -> > '(.+?)=(?P[-+ ]?\\d+\\.\\d+)(?P.+?)/s' > dtest: DEBUG: 5.681 > - >> end captured logging << - > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/compaction_test.py", line 280, in > compaction_throughput_test > self.assertGreaterEqual(float(threshold) + 0.5, float(avgthroughput)) > File "/usr/lib/python2.7/unittest/case.py", line 948, in assertGreaterEqual > self.fail(self._formatMessage(msg, standardMsg)) > File "/usr/lib/python2.7/unittest/case.py", line 410, in fail > raise self.failureException(msg) > "5.5 not greater than or equal to 5.681\n >> begin > captured logging << \ndtest: DEBUG: cluster ccm > directory: /tmp/dtest-FXOwMR\ndtest: DEBUG: Done setting configuration > options:\n{ 'num_tokens': None,\n'phi_convict_threshold': 5,\n > 'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms': > 1,\n'request_timeout_in_ms': 1,\n > 'truncate_request_timeout_in_ms': 1,\n'write_reques
[jira] [Created] (CASSANDRA-13195) Add dtest commit id to the CI builds
Aleksandr Sorokoumov created CASSANDRA-13195: Summary: Add dtest commit id to the CI builds Key: CASSANDRA-13195 URL: https://issues.apache.org/jira/browse/CASSANDRA-13195 Project: Cassandra Issue Type: Improvement Reporter: Aleksandr Sorokoumov Assignee: Michael Shuler Priority: Minor When investigating on the dtest-related issues, it might be useful to see dtest commit id in the Jenkins logs. AFAIK Jenkins clones dtest master right now. For example, it would be a bit easier to tackle some issues like CASSANDRA-13140 because one can immediately reproduce it with the same version of the dtest as used in the build and after that reason about the changes between this revision and the master using git history for the particular test. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13103) incorrect jvm metric names
[ https://issues.apache.org/jira/browse/CASSANDRA-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15856725#comment-15856725 ] Alain Rastoul commented on CASSANDRA-13103: --- Thank you for the review, Stefan. I checked the codahale metrics registry and the append method who adds the dot has been added in mars 2013 : https://github.com/dropwizard/metrics/commit/0ae1fc0292fa2f7509ab7f237f6a752e316a0d86 so IMHO this patch should be useful for any recent codahale library version use. > incorrect jvm metric names > -- > > Key: CASSANDRA-13103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13103 > Project: Cassandra > Issue Type: Bug > Components: Observability >Reporter: Alain Rastoul >Assignee: Alain Rastoul >Priority: Minor > Labels: lhf > Fix For: 3.9, 3.x > > Attachments: Fix-incorrect-jvm-metric-names-CASSANDRA-13103.patch > > > Some jvm metrics have a double dot in name like: > jvm.memory..total.max , jvm.memory..total.init (etc). > it seems that an extra dot is added at the end of the name in > CassandraDaemon.java, around line 367 (in 3.0.10): > ... > // enable metrics provided by metrics-jvm.jar > CassandraMetricsRegistry.Metrics.register("jvm.buffers.", new > BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer())); > CassandraMetricsRegistry.Metrics.register("jvm.gc.", new > GarbageCollectorMetricSet()); > CassandraMetricsRegistry.Metrics.register("jvm.memory.", new > MemoryUsageGaugeSet()); > and also added in append method of MetricRegistry. > Call stack is: > MetricRegistry>>registerAll(String prefix, MetricSet metrics) > MetricRegistry>>static String name(String name, String... names) > MetricRegistry>>static void append(StringBuilder builder, String part) > and in append the dot is also added: > ... > if(builder.length() > 0) { > builder.append('.'); > } > builder.append(part); > ... > The codahale MetricRegistry class seems to have no recent modification of > name or append methods, so it look like a small bug. > May be the fix could be to simply not to add the final dot in the metric > name, ie "jvm.buffers" instead of "jvm.buffers." -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13188) compaction-stress AssertionError from getMemtableFor()
[ https://issues.apache.org/jira/browse/CASSANDRA-13188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Zhuang updated CASSANDRA-13188: --- Attachment: 13188-3.11.txt > compaction-stress AssertionError from getMemtableFor() > -- > > Key: CASSANDRA-13188 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13188 > Project: Cassandra > Issue Type: Bug > Components: Testing, Tools >Reporter: Jay Zhuang >Assignee: Jay Zhuang > Attachments: 13188-3.11.txt > > > Exception: > {noformat} > ./compaction-stress compact -d /tmp/compaction -p > https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml > -t 4 > WARN 18:45:04,854 JNA link failure, one or more native method will be > unavailable. > java.lang.AssertionError: [] > at > org.apache.cassandra.db.lifecycle.Tracker.getMemtableFor(Tracker.java:312) > at > org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1315) > at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:618) > at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:462) > at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) > at org.apache.cassandra.db.Mutation.apply(Mutation.java:232) > at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) > at > org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:570) > at > org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:564) > at > org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:356) > at > org.apache.cassandra.schema.SchemaKeyspace.saveSystemKeyspacesSchema(SchemaKeyspace.java:265) > at > org.apache.cassandra.db.SystemKeyspace.finishStartup(SystemKeyspace.java:495) > at > org.apache.cassandra.stress.CompactionStress$Compaction.run(CompactionStress.java:209) > at > org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:349) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13188) compaction-stress AssertionError from getMemtableFor()
[ https://issues.apache.org/jira/browse/CASSANDRA-13188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Zhuang updated CASSANDRA-13188: --- Status: Patch Available (was: Open) > compaction-stress AssertionError from getMemtableFor() > -- > > Key: CASSANDRA-13188 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13188 > Project: Cassandra > Issue Type: Bug > Components: Testing, Tools >Reporter: Jay Zhuang >Assignee: Jay Zhuang > > Exception: > {noformat} > ./compaction-stress compact -d /tmp/compaction -p > https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml > -t 4 > WARN 18:45:04,854 JNA link failure, one or more native method will be > unavailable. > java.lang.AssertionError: [] > at > org.apache.cassandra.db.lifecycle.Tracker.getMemtableFor(Tracker.java:312) > at > org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1315) > at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:618) > at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:462) > at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) > at org.apache.cassandra.db.Mutation.apply(Mutation.java:232) > at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) > at > org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:570) > at > org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:564) > at > org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:356) > at > org.apache.cassandra.schema.SchemaKeyspace.saveSystemKeyspacesSchema(SchemaKeyspace.java:265) > at > org.apache.cassandra.db.SystemKeyspace.finishStartup(SystemKeyspace.java:495) > at > org.apache.cassandra.stress.CompactionStress$Compaction.run(CompactionStress.java:209) > at > org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:349) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13004) Corruption while adding a column to a table
[ https://issues.apache.org/jira/browse/CASSANDRA-13004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15856629#comment-15856629 ] Nimi Wariboko Jr. commented on CASSANDRA-13004: --- Update on our issue - I tried reproducing this on another fresh cluster and found I couldn't recreate the original table - it had a UDT that wasn't frozen. (Not sure when the frozen restriction was issued - but some time in the past you could create non-frozen UDT columns). I then dropped the table and recreated the table from the backup and the error seems to have gone away. > Corruption while adding a column to a table > --- > > Key: CASSANDRA-13004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13004 > Project: Cassandra > Issue Type: Bug >Reporter: Stanislav Vishnevskiy > > We had the following schema in production. > {code:none} > CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient ( > nick text > ); > CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite ( > id bigint, > type int, > allow_ int, > deny int > ); > CREATE TABLE IF NOT EXISTS discord_channels.channels ( > id bigint, > guild_id bigint, > type tinyint, > name text, > topic text, > position int, > owner_id bigint, > icon_hash text, > recipients map>, > permission_overwrites map>, > bitrate int, > user_limit int, > last_pin_timestamp timestamp, > last_message_id bigint, > PRIMARY KEY (id) > ); > {code} > And then we executed the following alter. > {code:none} > ALTER TABLE discord_channels.channels ADD application_id bigint; > {code} > And one row (that we can tell) got corrupted at the same time and could no > longer be read from the Python driver. > {code:none} > [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. > ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: > '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00 > > \x08\x01\x00\x00\x00\x04\xc4\xb4(\x00\xff\xff\xff\xff\x00\x00\x00O[f\x80Q\x07general\x05\xf8G\xc5\xffI\x98\xc4\xb4(\x00\xf8O[f\x80Q\x00\x00\x00\x02\x04\xf8O[f\x80Q\x00\xf8G\xc5\xffI\x98\x01\x00\x00\xf8O[f\x80Q\x00\x00\x00\x00\xf8G\xc5\xffI\x97\xc4\xb4(\x06\x00\xf8O\x7fe\x1fm\x08\x03\x00\x00\x00\x01\x00\x00\x00\x00\x04\x00\x00\x00\x00' > {code} > And then in cqlsh when trying to read the row we got this. > {code:none} > /usr/bin/cqlsh.py:632: DateOverFlowWarning: Some timestamps are larger than > Python datetime can represent. Timestamps are displayed in milliseconds from > epoch. > Traceback (most recent call last): > File "/usr/bin/cqlsh.py", line 1301, in perform_s
[jira] [Updated] (CASSANDRA-13190) Fix eclipse-warnings from CASSANDRA-9143
[ https://issues.apache.org/jira/browse/CASSANDRA-13190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-13190: Resolution: Fixed Fix Version/s: (was: 4.x) 4.0 Status: Resolved (was: Patch Available) and committed, thanks > Fix eclipse-warnings from CASSANDRA-9143 > > > Key: CASSANDRA-13190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13190 > Project: Cassandra > Issue Type: Sub-task > Components: Testing >Reporter: Michael Shuler >Assignee: Blake Eggleston > Labels: test-failure > Fix For: 4.0 > > > CASSANDRA-9143 introduced an error from eclipse-warnings: > {noformat} > # 2/7/17 5:50:30 AM UTC > # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp > 2000, 2013. All rights reserved. > -- > 1. ERROR in > /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/repair/consistent/PendingAntiCompaction.java > (at line 103) > return new AcquireResult(cfs, Refs.ref(sstables), txn); > ^^^ > Potential resource leak: 'txn' may not be closed at this location > -- > -- > 2. ERROR in > /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/db/compaction/PendingRepairManager.java > (at line 236) > return txn == null ? null : new RepairFinishedCompactionTask(cfs, txn, > sessionID, repairedAt); > > ^^ > Potential resource leak: 'txn' may not be closed at this location > -- > 2 problems (2 errors) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
cassandra git commit: Fix eclipse warnings after CASSANDRA-9143
Repository: cassandra Updated Branches: refs/heads/trunk 0409abc26 -> bd14400a9 Fix eclipse warnings after CASSANDRA-9143 Patch by Blake Eggleston; reviewed by marcuse for CASSANDRA-13190 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/bd14400a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/bd14400a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/bd14400a Branch: refs/heads/trunk Commit: bd14400a95c94b43f2a992d2263d81ae994721f2 Parents: 0409abc Author: Blake Eggleston Authored: Tue Feb 7 10:25:29 2017 -0800 Committer: Marcus Eriksson Committed: Tue Feb 7 10:31:29 2017 -0800 -- .../org/apache/cassandra/db/compaction/PendingRepairManager.java| 1 + .../apache/cassandra/repair/consistent/PendingAntiCompaction.java | 1 + 2 files changed, 2 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/bd14400a/src/java/org/apache/cassandra/db/compaction/PendingRepairManager.java -- diff --git a/src/java/org/apache/cassandra/db/compaction/PendingRepairManager.java b/src/java/org/apache/cassandra/db/compaction/PendingRepairManager.java index a270ead..27e8e9c 100644 --- a/src/java/org/apache/cassandra/db/compaction/PendingRepairManager.java +++ b/src/java/org/apache/cassandra/db/compaction/PendingRepairManager.java @@ -228,6 +228,7 @@ class PendingRepairManager return tasks; } +@SuppressWarnings("resource") private RepairFinishedCompactionTask getRepairFinishedCompactionTask(UUID sessionID) { Set sstables = get(sessionID).getSSTables(); http://git-wip-us.apache.org/repos/asf/cassandra/blob/bd14400a/src/java/org/apache/cassandra/repair/consistent/PendingAntiCompaction.java -- diff --git a/src/java/org/apache/cassandra/repair/consistent/PendingAntiCompaction.java b/src/java/org/apache/cassandra/repair/consistent/PendingAntiCompaction.java index 5203c41..dd71537 100644 --- a/src/java/org/apache/cassandra/repair/consistent/PendingAntiCompaction.java +++ b/src/java/org/apache/cassandra/repair/consistent/PendingAntiCompaction.java @@ -92,6 +92,7 @@ public class PendingAntiCompaction return Iterables.filter(cfs.getLiveSSTables(), s -> !s.isRepaired() && !s.isPendingRepair() && s.intersects(ranges)); } +@SuppressWarnings("resource") private AcquireResult acquireTuple() { List sstables = Lists.newArrayList(getSSTables());
[jira] [Updated] (CASSANDRA-13190) Fix eclipse-warnings from CASSANDRA-9143
[ https://issues.apache.org/jira/browse/CASSANDRA-13190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-13190: Reviewer: Marcus Eriksson > Fix eclipse-warnings from CASSANDRA-9143 > > > Key: CASSANDRA-13190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13190 > Project: Cassandra > Issue Type: Sub-task > Components: Testing >Reporter: Michael Shuler >Assignee: Blake Eggleston > Labels: test-failure > Fix For: 4.x > > > CASSANDRA-9143 introduced an error from eclipse-warnings: > {noformat} > # 2/7/17 5:50:30 AM UTC > # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp > 2000, 2013. All rights reserved. > -- > 1. ERROR in > /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/repair/consistent/PendingAntiCompaction.java > (at line 103) > return new AcquireResult(cfs, Refs.ref(sstables), txn); > ^^^ > Potential resource leak: 'txn' may not be closed at this location > -- > -- > 2. ERROR in > /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/db/compaction/PendingRepairManager.java > (at line 236) > return txn == null ? null : new RepairFinishedCompactionTask(cfs, txn, > sessionID, repairedAt); > > ^^ > Potential resource leak: 'txn' may not be closed at this location > -- > 2 problems (2 errors) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13190) Fix eclipse-warnings from CASSANDRA-9143
[ https://issues.apache.org/jira/browse/CASSANDRA-13190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-13190: Status: Patch Available (was: Open) fixed here: https://github.com/bdeggleston/cassandra/tree/13190 > Fix eclipse-warnings from CASSANDRA-9143 > > > Key: CASSANDRA-13190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13190 > Project: Cassandra > Issue Type: Sub-task > Components: Testing >Reporter: Michael Shuler >Assignee: Blake Eggleston > Labels: test-failure > Fix For: 4.x > > > CASSANDRA-9143 introduced an error from eclipse-warnings: > {noformat} > # 2/7/17 5:50:30 AM UTC > # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp > 2000, 2013. All rights reserved. > -- > 1. ERROR in > /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/repair/consistent/PendingAntiCompaction.java > (at line 103) > return new AcquireResult(cfs, Refs.ref(sstables), txn); > ^^^ > Potential resource leak: 'txn' may not be closed at this location > -- > -- > 2. ERROR in > /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/db/compaction/PendingRepairManager.java > (at line 236) > return txn == null ? null : new RepairFinishedCompactionTask(cfs, txn, > sessionID, repairedAt); > > ^^ > Potential resource leak: 'txn' may not be closed at this location > -- > 2 problems (2 errors) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CASSANDRA-13193) PK indices in 'Prepared' response can overflow
[ https://issues.apache.org/jira/browse/CASSANDRA-13193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Michallat resolved CASSANDRA-13193. --- Resolution: Duplicate Reproduced In: 3.9, 3.0.0 (was: 3.0.0, 3.9) JIRA glitch created this duplicate of CASSANDRA-13192, sorry. > PK indices in 'Prepared' response can overflow > -- > > Key: CASSANDRA-13193 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13193 > Project: Cassandra > Issue Type: Bug >Reporter: Olivier Michallat >Priority: Minor > > CASSANDRA-7660 added PK indices to the {{Prepared}} response. They are > encoded as shorts. > It's possible to prepare a query with more than 32768 placeholders (the hard > limit is 64K). For example, we sometimes see users running IN queries with > thousands of elements (a bad practice of course, but still possible). > When a PK component is present after the 32768th position, the PK index > overflows and a negative value is returned. This can throw off clients if > they're not prepared to handle it. For example, the Java driver currently > accepts the response, but will fail much later if you try to compute a bound > statement's routing key. > Failing fast would be safer here, the prepare query should error out if we > detect a PK index overflow. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CASSANDRA-13194) test failure in repair_tests.incremental_repair_test.TestIncRepair.compaction_test
Michael Shuler created CASSANDRA-13194: -- Summary: test failure in repair_tests.incremental_repair_test.TestIncRepair.compaction_test Key: CASSANDRA-13194 URL: https://issues.apache.org/jira/browse/CASSANDRA-13194 Project: Cassandra Issue Type: Bug Reporter: Michael Shuler Attachments: node1_debug.log, node1_gc.log, node1.log, node2_debug.log, node2_gc.log, node2.log, node3_debug.log, node3_gc.log, node3.log example failure: http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/333/testReport/repair_tests.incremental_repair_test/TestIncRepair/compaction_test {noformat} Error Message errors={'127.0.0.3': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.3 >> begin captured logging << dtest: DEBUG: cluster ccm directory: /tmp/dtest-2JszEQ dtest: DEBUG: Done setting configuration options: { 'num_tokens': None, 'phi_convict_threshold': 5, 'range_request_timeout_in_ms': 1, 'read_request_timeout_in_ms': 1, 'request_timeout_in_ms': 1, 'truncate_request_timeout_in_ms': 1, 'write_request_timeout_in_ms': 1} cassandra.policies: INFO: Using datacenter 'datacenter1' for DCAwareRoundRobinPolicy (via host '127.0.0.1'); if incorrect, please specify a local_dc to the constructor, or limit contact points to local cluster nodes cassandra.cluster: INFO: New Cassandra host discovered cassandra.cluster: INFO: New Cassandra host discovered - >> end captured logging << - Stacktrace File "/usr/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/home/automaton/cassandra-dtest/repair_tests/incremental_repair_test.py", line 225, in compaction_test create_ks(session, 'ks', 3) File "/home/automaton/cassandra-dtest/dtest.py", line 725, in create_ks session.execute(query % (name, "'class':'SimpleStrategy', 'replication_factor':%d" % rf)) File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 1998, in execute return self.execute_async(query, parameters, trace, custom_payload, timeout, execution_profile, paging_state).result() File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 3784, in result raise self._final_exception "errors={'127.0.0.3': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.3\n >> begin captured logging << \ndtest: DEBUG: cluster ccm directory: /tmp/dtest-2JszEQ\ndtest: DEBUG: Done setting configuration options:\n{ 'num_tokens': None,\n'phi_convict_threshold': 5,\n 'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n 'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms': 1}\ncassandra.policies: INFO: Using datacenter 'datacenter1' for DCAwareRoundRobinPolicy (via host '127.0.0.1'); if incorrect, please specify a local_dc to the constructor, or limit contact points to local cluster nodes\ncassandra.cluster: INFO: New Cassandra host discovered\ncassandra.cluster: INFO: New Cassandra host discovered\n- >> end captured logging << -" {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CASSANDRA-13192) PK indices in 'Prepared' response can overflow
Olivier Michallat created CASSANDRA-13192: - Summary: PK indices in 'Prepared' response can overflow Key: CASSANDRA-13192 URL: https://issues.apache.org/jira/browse/CASSANDRA-13192 Project: Cassandra Issue Type: Bug Reporter: Olivier Michallat Priority: Minor CASSANDRA-7660 added PK indices to the {{Prepared}} response. They are encoded as shorts. It's possible to prepare a query with more than 32768 placeholders (the hard limit is 64K). For example, we sometimes see users running IN queries with thousands of elements (a bad practice of course, but still possible). When a PK component is present after the 32768th position, the PK index overflows and a negative value is returned. This can throw off clients if they're not prepared to handle it. For example, the Java driver currently accepts the response, but will fail much later if you try to compute a bound statement's routing key. Failing fast would be safer here, the prepare query should error out if we detect a PK index overflow. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CASSANDRA-13193) PK indices in 'Prepared' response can overflow
Olivier Michallat created CASSANDRA-13193: - Summary: PK indices in 'Prepared' response can overflow Key: CASSANDRA-13193 URL: https://issues.apache.org/jira/browse/CASSANDRA-13193 Project: Cassandra Issue Type: Bug Reporter: Olivier Michallat Priority: Minor CASSANDRA-7660 added PK indices to the {{Prepared}} response. They are encoded as shorts. It's possible to prepare a query with more than 32768 placeholders (the hard limit is 64K). For example, we sometimes see users running IN queries with thousands of elements (a bad practice of course, but still possible). When a PK component is present after the 32768th position, the PK index overflows and a negative value is returned. This can throw off clients if they're not prepared to handle it. For example, the Java driver currently accepts the response, but will fail much later if you try to compute a bound statement's routing key. Failing fast would be safer here, the prepare query should error out if we detect a PK index overflow. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CASSANDRA-13191) test failure in org.apache.cassandra.hints.HintsBufferPoolTest.testBackpressure
Michael Shuler created CASSANDRA-13191: -- Summary: test failure in org.apache.cassandra.hints.HintsBufferPoolTest.testBackpressure Key: CASSANDRA-13191 URL: https://issues.apache.org/jira/browse/CASSANDRA-13191 Project: Cassandra Issue Type: Bug Reporter: Michael Shuler example failure: http://cassci.datastax.com/job/trunk_testall/1392/testReport/org.apache.cassandra.hints/HintsBufferPoolTest/testBackpressure {noformat} Error Message Connection reset Stacktrace java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:209) at java.net.SocketInputStream.read(SocketInputStream.java:141) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) at java.io.InputStreamReader.read(InputStreamReader.java:184) at java.io.BufferedReader.fill(BufferedReader.java:161) at java.io.BufferedReader.readLine(BufferedReader.java:324) at java.io.BufferedReader.readLine(BufferedReader.java:389) at org.jboss.byteman.agent.submit.Submit$Comm.readResponse(Submit.java:941) at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:790) at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:603) at org.jboss.byteman.contrib.bmunit.BMUnit.loadScriptText(BMUnit.java:268) at org.jboss.byteman.contrib.bmunit.BMUnitRunner$10.evaluate(BMUnitRunner.java:369) at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) Standard Output ERROR [main] 2017-02-07 11:03:07,465 ?:? - SLF4J: stderr INFO [main] 2017-02-07 11:03:07,650 ?:? - Configuration location: file:/home/automaton/cassandra/test/conf/cassandra.yaml DEBUG [main] 2017-02-07 11:03:07,651 ?:? - Loading settings from file:/home/automaton/cassandra/test/conf/cassandra.yaml INFO [main] 2017-02-07 11:03:08,225 ?:? - Node configuration:[allocate_tokens_for_keyspace=null; authenticator=null; authorizer=null; auto_bootstrap=true; auto_snapshot=true; back_pressure_enabled=false; back_pressure_strategy=null; batch_size_fail_threshold_in_kb=50; batch_size_warn_threshold_in_kb=5; batchlog_replay_throttle_in_kb=1024; broadcast_address=null; broadcast_rpc_address=null; buffer_pool_use_heap_if_exhausted=true; cas_contention_timeout_in_ms=1000; cdc_enabled=false; cdc_free_space_check_interval_ms=250; cdc_raw_directory=build/test/cassandra/cdc_raw:222; cdc_total_space_in_mb=0; client_encryption_options=; cluster_name=Test Cluster; column_index_cache_size_in_kb=2; column_index_size_in_kb=4; commit_failure_policy=stop; commitlog_compression=null; commitlog_directory=build/test/cassandra/commitlog:222; commitlog_max_compression_buffers_in_pool=3; commitlog_periodic_queue_size=-1; commitlog_segment_size_in_mb=5; commitlog_sync=batch; commitlog_sync_batch_window_in_ms=1.0; commitlog_sync_period_in_ms=0; commitlog_total_space_in_mb=null; compaction_large_partition_warning_threshold_mb=100; compaction_throughput_mb_per_sec=0; concurrent_compactors=4; concurrent_counter_writes=32; concurrent_materialized_view_writes=32; concurrent_reads=32; concurrent_replicates=null; concurrent_writes=32; counter_cache_keys_to_save=2147483647; counter_cache_save_period=7200; counter_cache_size_in_mb=null; counter_write_request_timeout_in_ms=5000; credentials_cache_max_entries=1000; credentials_update_interval_in_ms=-1; credentials_validity_in_ms=2000; cross_node_timeout=false; data_file_directories=[Ljava.lang.String;@e7edb54; disk_access_mode=mmap; disk_failure_policy=ignore; disk_optimization_estimate_percentile=0.95; disk_optimization_page_cross_chance=0.1; disk_optimization_strategy=ssd; dynamic_snitch=true; dynamic_snitch_badness_threshold=0.1; dynamic_snitch_reset_interval_in_ms=60; dynamic_snitch_update_interval_in_ms=100; enable_scripted_user_defined_functions=true; enable_user_defined_functions=true; enable_user_defined_functions_threads=true; encryption_options=null; endpoint_snitch=org.apache.cassandra.locator.SimpleSnitch; file_cache_size_in_mb=null; gc_log_threshold_in_ms=200; gc_warn_threshold_in_ms=0; hinted_handoff_disabled_datacenters=[]; hinted_handoff_enabled=true; hinted_handoff_throttle_in_kb=1024; hints_compression=null; hints_directory=build/test/cassandra/hints:222; hints_flush_period_in_ms=1; incremental_backups=true; index_interval=null; index_summary_capacity_in_mb=null; index_summary_resize_interval_in_minutes=60; initial_token=null; inter_dc_stream_throughput_outbound_megabits_per_sec=200; inter_dc_tcp_nodelay=true; internode_authenticator=null; internode_compression=none; internode_recv_buff_siz
[jira] [Assigned] (CASSANDRA-11635) test-clientutil-jar unit test fails
[ https://issues.apache.org/jira/browse/CASSANDRA-11635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne reassigned CASSANDRA-11635: Assignee: (was: Sylvain Lebresne) > test-clientutil-jar unit test fails > --- > > Key: CASSANDRA-11635 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11635 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Michael Shuler > Labels: unittest > Fix For: 2.2.x, 3.0.x, 3.x > > > {noformat} > test-clientutil-jar: > [junit] Testsuite: org.apache.cassandra.serializers.ClientUtilsTest > [junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: > 0.314 sec > [junit] > [junit] Testcase: test(org.apache.cassandra.serializers.ClientUtilsTest): > Caused an ERROR > [junit] org/apache/cassandra/utils/SigarLibrary > [junit] java.lang.NoClassDefFoundError: > org/apache/cassandra/utils/SigarLibrary > [junit] at org.apache.cassandra.utils.UUIDGen.hash(UUIDGen.java:328) > [junit] at > org.apache.cassandra.utils.UUIDGen.makeNode(UUIDGen.java:307) > [junit] at > org.apache.cassandra.utils.UUIDGen.makeClockSeqAndNode(UUIDGen.java:256) > [junit] at > org.apache.cassandra.utils.UUIDGen.(UUIDGen.java:39) > [junit] at > org.apache.cassandra.serializers.ClientUtilsTest.test(ClientUtilsTest.java:56) > [junit] Caused by: java.lang.ClassNotFoundException: > org.apache.cassandra.utils.SigarLibrary > [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > [junit] at > sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > [junit] > [junit] > [junit] Test org.apache.cassandra.serializers.ClientUtilsTest FAILED > BUILD FAILED > {noformat} > I'll see if I can find a spot where this passes, but it appears to have been > failing for a long time. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CASSANDRA-13190) Fix eclipse-warnings from CASSANDRA-9143
Michael Shuler created CASSANDRA-13190: -- Summary: Fix eclipse-warnings from CASSANDRA-9143 Key: CASSANDRA-13190 URL: https://issues.apache.org/jira/browse/CASSANDRA-13190 Project: Cassandra Issue Type: Sub-task Components: Testing Reporter: Michael Shuler Assignee: Blake Eggleston Fix For: 4.x CASSANDRA-9143 introduced an error from eclipse-warnings: {noformat} # 2/7/17 5:50:30 AM UTC # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp 2000, 2013. All rights reserved. -- 1. ERROR in /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/repair/consistent/PendingAntiCompaction.java (at line 103) return new AcquireResult(cfs, Refs.ref(sstables), txn); ^^^ Potential resource leak: 'txn' may not be closed at this location -- -- 2. ERROR in /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/db/compaction/PendingRepairManager.java (at line 236) return txn == null ? null : new RepairFinishedCompactionTask(cfs, txn, sessionID, repairedAt); ^^ Potential resource leak: 'txn' may not be closed at this location -- 2 problems (2 errors) {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13096) Snapshots slow down jmx scraping
[ https://issues.apache.org/jira/browse/CASSANDRA-13096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-13096: Summary: Snapshots slow down jmx scraping (was: Snapshots slow down jmx scrapping) > Snapshots slow down jmx scraping > > > Key: CASSANDRA-13096 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13096 > Project: Cassandra > Issue Type: Bug >Reporter: Maxime Fouilleul > Attachments: Clear Snapshots.png, CPU Load.png, JMX Scrape > Duration.png > > > Hello, > We are scraping the jmx metrics through a prometheus exporter and we noticed > that some nodes became really long to answer (more than 20 seconds). After > some investigations we do not find any hardware problem or overload issues on > there "slow" nodes. It happens on different clusters, some with only few giga > bytes of dataset and it does not seams to be related to a specific version > neither as it happens on 2.1, 2.2 and 3.0 nodes. > After some unsuccessful actions, one of our ideas was to clean the snapshots > staying on one problematic node: > {code} > nodetool clearsnapshot > {code} > And the magic happens... as you can see in the attached diagrams, the second > we cleared the snapshots, the CPU activity dropped immediatly and the > duration to scrape the jmx metrics goes from +20 secs to instantaneous... > Can you enlighten us on this issue? Once again, it appears on our three 2.1, > 2.2 and 3.0 versions, on different volumetry and it is not systematically > linked to the snapshots as we have some nodes with the same snapshots volume > which are going pretty well. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13130) Strange result of several list updates in a single request
[ https://issues.apache.org/jira/browse/CASSANDRA-13130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-13130: Priority: Trivial (was: Critical) > Strange result of several list updates in a single request > -- > > Key: CASSANDRA-13130 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13130 > Project: Cassandra > Issue Type: Bug >Reporter: Mikhail Krupitskiy >Priority: Trivial > > Let's assume that we have a row with the 'listColumn' column and value > \{1,2,3,4\}. > For me it looks logical to expect that the following two pieces of code will > ends up with the same result but it isn't so. > Code1: > {code} > UPDATE t SET listColumn[2] = 7, listColumn[2] = 8 WHERE id = 1; > {code} > Expected result: listColumn=\{1,2,8,4\} > Actual result: listColumn=\{1,2,7,8,4\} > Code2: > {code} > UPDATE t SET listColumn[2] = 7 WHERE id = 1; > UPDATE t SET listColumn[2] = 8 WHERE id = 1; > {code} > Expected result: listColumn=\{1,2,8,4\} > Actual result: listColumn=\{1,2,8,4\} > So the question is why Code1 and Code2 give different results? > Looks like Code1 should give the same result as Code2. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-12497) COPY ... TO STDOUT regression in 2.2.7
[ https://issues.apache.org/jira/browse/CASSANDRA-12497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15856060#comment-15856060 ] ASF GitHub Bot commented on CASSANDRA-12497: GitHub user salomvary opened a pull request: https://github.com/apache/cassandra/pull/92 Fix failing COPY ... TO STDOUT Fixes [CASSANDRA-12497](https://issues.apache.org/jira/browse/CASSANDRA-12497). You can merge this pull request into a Git repository by running: $ git pull https://github.com/salomvary/cassandra fix-copy-to-stdout Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cassandra/pull/92.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #92 commit 43b46a9cf2a4a190ce0e3b69b1b21ddf1a10 Author: Márton Salomváry Date: 2017-02-07T14:15:34Z Fix failing COPY ... TO STDOUT Fixed CASSANDRA-12497 > COPY ... TO STDOUT regression in 2.2.7 > -- > > Key: CASSANDRA-12497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12497 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Max Bowsher >Assignee: Tyler Hobbs > > Cassandra 2.2.7 introduces a regression over 2.2.6 breaking COPY ... TO > STDOUT. > In pylib/cqlshlib/copyutil.py, in CopyTask.__init__, self.printmsg is > conditionally defined to EITHER a module level function accepting arguments > (msg, eol=, encoding=), OR a lambda accepting arguments only (_, eol=). > Consequently, when the lambda is in use (which requires COPY ... TO STDOUT > without --debug), any attempt to call CopyTask.printmsg with an encoding > parameter causes an exception. > This occurs in ExportTask.run, thus rendering all COPY ... TO STDOUT without > --debug broken. > The fix is to update the lambda's arguments to include encoding, or better, > replace it with a module-level function defined next to printmsg, so that > people realize the two argument lists must be kept in sync. > The regression was introduced in this commit: > commit 5de9de1f5832f2a0e92783e2f4412874423e6e15 > Author: Tyler Hobbs > Date: Thu May 5 11:33:35 2016 -0500 > cqlsh: Handle non-ascii chars in error messages > > Patch by Tyler Hobbs; reviewed by Paulo Motta for CASSANDRA-11626 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13120) Trace and Histogram output misleading
[ https://issues.apache.org/jira/browse/CASSANDRA-13120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15855904#comment-15855904 ] Benjamin Lerer commented on CASSANDRA-13120: bq. Out of all sstables candidates for a file, only sstables which return non null from BigTableReader will add up to result. I would prefer to not use that approach as it could break quite easily without anybody noticing. If somebody was replacing the reader by an {{Optional}} for example. To be honest, I am not sure yet how to fix it in the best way which is why I want to think a bit about it. > Trace and Histogram output misleading > - > > Key: CASSANDRA-13120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13120 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Adam Hattrell >Assignee: Benjamin Lerer >Priority: Minor > > If we look at the following output: > {noformat} > [centos@cassandra-c-3]$ nodetool getsstables -- keyspace table > 60ea4399-6b9f-4419-9ccb-ff2e6742de10 > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647146-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647147-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647145-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647152-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647157-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-648137-big-Data.db > {noformat} > We can see that this key value appears in just 6 sstables. However, when we > run a select against the table and key we get: > {noformat} > Tracing session: a6c81330-d670-11e6-b00b-c1d403fd6e84 > activity > | timestamp | source > | source_elapsed > ---+++ > > Execute CQL3 query | 2017-01-09 13:36:40.419000 | > 10.200.254.141 | 0 > Parsing SELECT * FROM keyspace.table WHERE id = > 60ea4399-6b9f-4419-9ccb-ff2e6742de10; [SharedPool-Worker-2] | > 2017-01-09 13:36:40.419000 | 10.200.254.141 |104 > > Preparing statement [SharedPool-Worker-2] | 2017-01-09 13:36:40.419000 | > 10.200.254.141 |220 > Executing single-partition query on > table [SharedPool-Worker-1]| 2017-01-09 13:36:40.419000 | > 10.200.254.141 |450 > Acquiring > sstable references [SharedPool-Worker-1] | 2017-01-09 13:36:40.419000 | > 10.200.254.141 |477 > Bloom filter allows skipping > sstable 648146 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419000 | > 10.200.254.141 |496 > Bloom filter allows skipping > sstable 648145 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |503 > Key cache hit for > sstable 648140 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |513 > Bloom filter allows skipping > sstable 648135 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |520 > Bloom filter allows skipping > sstable 648130 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |526 > Bloom filter allows skipping > sstable 648048 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |530 > Bloom filter allows skipping > sstable 647749 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |535 > Bloom filter allows skipping > sstable 647404 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |540 > Key cache hit for > sstable 647145 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |548 >
[jira] [Commented] (CASSANDRA-13120) Trace and Histogram output misleading
[ https://issues.apache.org/jira/browse/CASSANDRA-13120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15855844#comment-15855844 ] Nenad commented on CASSANDRA-13120: --- Basically counter is incremented ({noformat}sstablesIterated{noformat}) on each loop no matter if Bloom Filter says it should be skipped or not. I was waiting for someone to check if that is intended or not. I have suggestion how we can fix that (I can create a patch as well). Out of all sstables candidates for a file, only sstables which return non null from BigTableReader (https://github.com/apache/cassandra/blob/af3fe39dcabd9ef77a00309ce6741268423206df/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java) will add up to result. Read path and this code is executed from this line (https://github.com/apache/cassandra/blob/cassandra-3.0.10/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java#L584). We can introduce counter {noformat}sstablesWithData{noformat} if {noformat}sstablesIterated{noformat} is used somewhere else, and increment {noformat}sstablesWithData{noformat} only when {noformat}iter{noformat} has non-null result returned from BigTableReader. What do you think? That would give correct number of sstables based on read path including Bloom Filter. > Trace and Histogram output misleading > - > > Key: CASSANDRA-13120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13120 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Adam Hattrell >Assignee: Benjamin Lerer >Priority: Minor > > If we look at the following output: > {noformat} > [centos@cassandra-c-3]$ nodetool getsstables -- keyspace table > 60ea4399-6b9f-4419-9ccb-ff2e6742de10 > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647146-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647147-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647145-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647152-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647157-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-648137-big-Data.db > {noformat} > We can see that this key value appears in just 6 sstables. However, when we > run a select against the table and key we get: > {noformat} > Tracing session: a6c81330-d670-11e6-b00b-c1d403fd6e84 > activity > | timestamp | source > | source_elapsed > ---+++ > > Execute CQL3 query | 2017-01-09 13:36:40.419000 | > 10.200.254.141 | 0 > Parsing SELECT * FROM keyspace.table WHERE id = > 60ea4399-6b9f-4419-9ccb-ff2e6742de10; [SharedPool-Worker-2] | > 2017-01-09 13:36:40.419000 | 10.200.254.141 |104 > > Preparing statement [SharedPool-Worker-2] | 2017-01-09 13:36:40.419000 | > 10.200.254.141 |220 > Executing single-partition query on > table [SharedPool-Worker-1]| 2017-01-09 13:36:40.419000 | > 10.200.254.141 |450 > Acquiring > sstable references [SharedPool-Worker-1] | 2017-01-09 13:36:40.419000 | > 10.200.254.141 |477 > Bloom filter allows skipping > sstable 648146 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419000 | > 10.200.254.141 |496 > Bloom filter allows skipping > sstable 648145 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |503 > Key cache hit for > sstable 648140 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |513 > Bloom filter allows skipping > sstable 648135 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |520 > Bloom filter allows skipping > sstable 648130 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |526 > Blo
[jira] [Comment Edited] (CASSANDRA-13120) Trace and Histogram output misleading
[ https://issues.apache.org/jira/browse/CASSANDRA-13120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15855844#comment-15855844 ] Nenad edited comment on CASSANDRA-13120 at 2/7/17 12:04 PM: Basically counter is incremented (_sstablesIterated_) on each loop no matter if Bloom Filter says it should be skipped or not. I was waiting for someone to check if that is intended or not. I have suggestion how we can fix that (I can create a patch as well). Out of all sstables candidates for a file, only sstables which return non null from [BigTableReader| https://github.com/apache/cassandra/blob/af3fe39dcabd9ef77a00309ce6741268423206df/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java] will add up to result. Read path and this code is executed from [this line|https://github.com/apache/cassandra/blob/cassandra-3.0.10/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java#L584]. We can introduce counter _sstablesWithData_ if _sstablesIterated_ is used somewhere else, and increment _sstablesWithData_ only when _iter_ has non-null result returned from BigTableReader. What do you think? That would give correct number of sstables based on read path including Bloom Filter. was (Author: nbozicns): Basically counter is incremented ({noformat}sstablesIterated{noformat}) on each loop no matter if Bloom Filter says it should be skipped or not. I was waiting for someone to check if that is intended or not. I have suggestion how we can fix that (I can create a patch as well). Out of all sstables candidates for a file, only sstables which return non null from BigTableReader (https://github.com/apache/cassandra/blob/af3fe39dcabd9ef77a00309ce6741268423206df/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java) will add up to result. Read path and this code is executed from this line (https://github.com/apache/cassandra/blob/cassandra-3.0.10/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java#L584). We can introduce counter {noformat}sstablesWithData{noformat} if {noformat}sstablesIterated{noformat} is used somewhere else, and increment {noformat}sstablesWithData{noformat} only when {noformat}iter{noformat} has non-null result returned from BigTableReader. What do you think? That would give correct number of sstables based on read path including Bloom Filter. > Trace and Histogram output misleading > - > > Key: CASSANDRA-13120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13120 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Adam Hattrell >Assignee: Benjamin Lerer >Priority: Minor > > If we look at the following output: > {noformat} > [centos@cassandra-c-3]$ nodetool getsstables -- keyspace table > 60ea4399-6b9f-4419-9ccb-ff2e6742de10 > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647146-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647147-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647145-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647152-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647157-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-648137-big-Data.db > {noformat} > We can see that this key value appears in just 6 sstables. However, when we > run a select against the table and key we get: > {noformat} > Tracing session: a6c81330-d670-11e6-b00b-c1d403fd6e84 > activity > | timestamp | source > | source_elapsed > ---+++ > > Execute CQL3 query | 2017-01-09 13:36:40.419000 | > 10.200.254.141 | 0 > Parsing SELECT * FROM keyspace.table WHERE id = > 60ea4399-6b9f-4419-9ccb-ff2e6742de10; [SharedPool-Worker-2] | > 2017-01-09 13:36:40.419000 | 10.200.254.141 |104 > > Preparing statement [SharedPool-Worker-2] | 2017-01-09 13:36:40.419000 | > 10.200.254.141 |220 > Executing single-partition query on > table [SharedPool-Worker-1]| 2017-01-09 13:36:40.419000 | > 10.200.254.141 |450 >
[jira] [Commented] (CASSANDRA-13120) Trace and Histogram output misleading
[ https://issues.apache.org/jira/browse/CASSANDRA-13120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15855711#comment-15855711 ] Benjamin Lerer commented on CASSANDRA-13120: The trace and histogram output are effectively wrong. The problem is caused by the fact that the code within {{SinglePartitionReadCommand}} is not aware of which SSTables are skipped due to the Bloom filters. I will try to find a way to correct that problem. > Trace and Histogram output misleading > - > > Key: CASSANDRA-13120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13120 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Adam Hattrell >Assignee: Benjamin Lerer >Priority: Minor > > If we look at the following output: > {noformat} > [centos@cassandra-c-3]$ nodetool getsstables -- keyspace table > 60ea4399-6b9f-4419-9ccb-ff2e6742de10 > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647146-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647147-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647145-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647152-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-647157-big-Data.db > /mnt/cassandra/data/data/keyspace/table-62f30431acf411e69a4ed7dd11246f8a/mc-648137-big-Data.db > {noformat} > We can see that this key value appears in just 6 sstables. However, when we > run a select against the table and key we get: > {noformat} > Tracing session: a6c81330-d670-11e6-b00b-c1d403fd6e84 > activity > | timestamp | source > | source_elapsed > ---+++ > > Execute CQL3 query | 2017-01-09 13:36:40.419000 | > 10.200.254.141 | 0 > Parsing SELECT * FROM keyspace.table WHERE id = > 60ea4399-6b9f-4419-9ccb-ff2e6742de10; [SharedPool-Worker-2] | > 2017-01-09 13:36:40.419000 | 10.200.254.141 |104 > > Preparing statement [SharedPool-Worker-2] | 2017-01-09 13:36:40.419000 | > 10.200.254.141 |220 > Executing single-partition query on > table [SharedPool-Worker-1]| 2017-01-09 13:36:40.419000 | > 10.200.254.141 |450 > Acquiring > sstable references [SharedPool-Worker-1] | 2017-01-09 13:36:40.419000 | > 10.200.254.141 |477 > Bloom filter allows skipping > sstable 648146 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419000 | > 10.200.254.141 |496 > Bloom filter allows skipping > sstable 648145 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |503 > Key cache hit for > sstable 648140 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |513 > Bloom filter allows skipping > sstable 648135 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |520 > Bloom filter allows skipping > sstable 648130 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |526 > Bloom filter allows skipping > sstable 648048 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |530 > Bloom filter allows skipping > sstable 647749 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |535 > Bloom filter allows skipping > sstable 647404 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |540 > Key cache hit for > sstable 647145 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | > 10.200.254.141 |548 > Key cache hit for > sstable 647146 [SharedPool-Worker-1] | 2017-01-09 13:36:40.419001 | >
[jira] [Resolved] (CASSANDRA-7461) operator functionality in CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-7461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer resolved CASSANDRA-7461. --- Resolution: Fixed All the sub-tasks have been committed. > operator functionality in CQL > - > > Key: CASSANDRA-7461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7461 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Robert Stupp >Assignee: Benjamin Lerer > Labels: cql > > Intention: Allow operators in CQL > Operators could be decimal arithmetics {{+ - * /}} or boolen arithmetics {{| > & !}} or string 'arithmetics' {{+}} > {{SELECT tab.label + ' = ' + tab.value FROM foo.tab}} > {{SELECT * FROM tab WHERE tab.label + ' = ' + tab.value = 'foo = bar'}} > as well as > {{CREATE INDEX idx ON tab ( tab.tabel + '=' + tab.value )}} > or > {{CREATE INDEX idx ON tab (label) WHERE contains(tab.tabel, > 'very-important-key')}} > Operators could be mapped to UDFs like this: > {{+}} mapped to UDF {{cstarstd::oper_plus(...)}} > {{-}} mapped to UDF {{cstarstd::oper_minus(...)}} > or handled directly via {{Cql.g}} in 'special' code -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-11936) Add support for + and - operations on dates
[ https://issues.apache.org/jira/browse/CASSANDRA-11936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-11936: --- Resolution: Fixed Fix Version/s: (was: 3.x) 4.0 Status: Resolved (was: Ready to Commit) Committed in trunk at 0409abc26a9bd0dba59bccb37c668f6608dd6ab9 > Add support for + and - operations on dates > --- > > Key: CASSANDRA-11936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11936 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer > Fix For: 4.0 > > > For time series it can be interesting to allow queries with {{WHERE}} clause > like: {{... WHERE reading_time < now() - 2h}} > In order to do that we need to add support for: {{+}} and {{-}} operation > with date. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
cassandra git commit: Add support for + and - operations on dates
Repository: cassandra Updated Branches: refs/heads/trunk 0564c8b42 -> 0409abc26 Add support for + and - operations on dates patch by Benjamin Lerer; reviewed by Alex Petrov for CASSANDRA-11936 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0409abc2 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0409abc2 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0409abc2 Branch: refs/heads/trunk Commit: 0409abc26a9bd0dba59bccb37c668f6608dd6ab9 Parents: 0564c8b Author: Benjamin Lerer Authored: Tue Feb 7 11:24:22 2017 +0100 Committer: Benjamin Lerer Committed: Tue Feb 7 11:24:22 2017 +0100 -- CHANGES.txt | 1 + NEWS.txt| 6 + doc/source/cql/operators.rst| 29 ++- .../org/apache/cassandra/cql3/Duration.java | 72 .../cassandra/cql3/functions/CastFcts.java | 10 +- .../cassandra/cql3/functions/OperationFcts.java | 144 +++ .../cassandra/cql3/functions/TimeFcts.java | 177 +++ .../cassandra/db/marshal/SimpleDateType.java| 16 +- .../cassandra/db/marshal/TemporalType.java | 103 +++ .../apache/cassandra/db/marshal/TimeType.java | 2 +- .../cassandra/db/marshal/TimeUUIDType.java | 28 ++- .../cassandra/db/marshal/TimestampType.java | 21 ++- .../org/apache/cassandra/cql3/DurationTest.java | 78 +++- .../cql3/functions/OperationFctsTest.java | 98 ++ .../cassandra/cql3/functions/TimeFctsTest.java | 19 +- 15 files changed, 636 insertions(+), 168 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0409abc2/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index e1708b7..905a750 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0 + * Add support for + and - operations on dates (CASSANDRA-11936) * Fix consistency of incrementally repaired data (CASSANDRA-9143) * Increase commitlog version (CASSANDRA-13161) * Make TableMetadata immutable, optimize Schema (CASSANDRA-9425) http://git-wip-us.apache.org/repos/asf/cassandra/blob/0409abc2/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index ee1fd6d..9c183f6 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -18,6 +18,12 @@ using the provided 'sstableupgrade' tool. New features + - Support for arithmetic operations between `timestamp`/`date` and `duration` has been added. + See CASSANDRA-11936 + - Support for arithmetic operations on number has been added. See CASSANDRA-11935 + +3.11 + Upgrading - http://git-wip-us.apache.org/repos/asf/cassandra/blob/0409abc2/doc/source/cql/operators.rst -- diff --git a/doc/source/cql/operators.rst b/doc/source/cql/operators.rst index 05f1c61..45f52d9 100644 --- a/doc/source/cql/operators.rst +++ b/doc/source/cql/operators.rst @@ -17,6 +17,8 @@ .. highlight:: cql .. _arithmetic_operators: +.. _number-arithmetic: +.. _datetime--arithmetic: Arithmetic Operators @@ -26,15 +28,20 @@ CQL supports the following operators: === === OperatorDescription === === - \- (unary) Negates operand - \+ Addition - \- Substraction - \* Multiplication + \- (unary) Negates operand + \+ Addition + \- Substraction + \* Multiplication / Division % Returns the remainder of a division === === -Arithmetic operations are only supported on numeric types or counters. +.. _number-arithmetic: + +Number Arithmetic +^ + +All arithmetic operations are supported on numeric types or counters. The return type of the operation will be based on the operand types: @@ -55,3 +62,15 @@ The return type of the operation will be based on the operand types: ``*``, ``/`` and ``%`` operators have a higher precedence level than ``+`` and ``-`` operator. By consequence, they will be evaluated before. If two operator in an expression have the same precedence level, they will be evaluated left to right based on their position in the expression. + +.. _datetime--arithmetic: + +Datetime Arithmetic +^^^ + +A ``duration`` can be added (+) or subs
[jira] [Updated] (CASSANDRA-13152) UPDATE on counter columns with empty list as argument in IN disables cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-13152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-13152: --- Resolution: Fixed Fix Version/s: (was: 4.x) (was: 3.0.x) (was: 3.x) 4.0 3.11.0 3.0.11 Status: Resolved (was: Ready to Commit) Committed into 3.0 at fb606dd41c9f14324749efc1344421237c36a6db and merged into 3.11 and trunk > UPDATE on counter columns with empty list as argument in IN disables cluster > > > Key: CASSANDRA-13152 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13152 > Project: Cassandra > Issue Type: Bug > Environment: Linux Ubuntu 16 > 3 Virtual machines >Reporter: jorge collinet >Assignee: Benjamin Lerer > Fix For: 3.0.11, 3.11.0, 4.0 > > > On a 3 node cluster > with this table (replication factor of 2): > {code} > CREATE TABLE tracking.item_items_rec_history ( > reference_id bigint, > country text, > portal text, > app_name text, > recommended_id bigint, > counter counter, > PRIMARY KEY (reference_id, country, portal, app_name, recommended_id) > ); > {code} > If I execute > {code} > UPDATE user_items_rec_history > SET counter = counter + 1 > WHERE reference_id = 1 AND country = '' AND portal = '' AND app_name = '' AND > recommended_id IN (); > {code} > Take note that the IN is empty > The cluster starts to malfunction and responds a lot of timeouts to any query. > After resetting some of the nodes, the cluster starts to function normally > again. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13152) UPDATE on counter columns with empty list as argument in IN disables cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-13152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15855666#comment-15855666 ] Benjamin Lerer commented on CASSANDRA-13152: Thanks for the review. > UPDATE on counter columns with empty list as argument in IN disables cluster > > > Key: CASSANDRA-13152 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13152 > Project: Cassandra > Issue Type: Bug > Environment: Linux Ubuntu 16 > 3 Virtual machines >Reporter: jorge collinet >Assignee: Benjamin Lerer > Fix For: 3.0.x, 3.x, 4.x > > > On a 3 node cluster > with this table (replication factor of 2): > {code} > CREATE TABLE tracking.item_items_rec_history ( > reference_id bigint, > country text, > portal text, > app_name text, > recommended_id bigint, > counter counter, > PRIMARY KEY (reference_id, country, portal, app_name, recommended_id) > ); > {code} > If I execute > {code} > UPDATE user_items_rec_history > SET counter = counter + 1 > WHERE reference_id = 1 AND country = '' AND portal = '' AND app_name = '' AND > recommended_id IN (); > {code} > Take note that the IN is empty > The cluster starts to malfunction and responds a lot of timeouts to any query. > After resetting some of the nodes, the cluster starts to function normally > again. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[1/3] cassandra git commit: Fix UPDATE queries with empty IN restrictions
Repository: cassandra Updated Branches: refs/heads/trunk 98d74ed99 -> 0564c8b42 Fix UPDATE queries with empty IN restrictions patch by Benjamin Lerer; reviewed by Alex Petrov for CASSANDRA-13152 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fb606dd4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fb606dd4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fb606dd4 Branch: refs/heads/trunk Commit: fb606dd41c9f14324749efc1344421237c36a6db Parents: dab0e31 Author: Benjamin Lerer Authored: Tue Feb 7 10:35:48 2017 +0100 Committer: Benjamin Lerer Committed: Tue Feb 7 10:35:48 2017 +0100 -- CHANGES.txt | 1 + .../cql3/statements/ModificationStatement.java | 4 ++ .../cql3/validation/operations/DeleteTest.java | 54 .../cql3/validation/operations/UpdateTest.java | 53 ++- 4 files changed, 111 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb606dd4/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 1a90b1f..4387019 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.0.11 + * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152) * Abort or retry on failed hints delivery (CASSANDRA-13124) * Fix handling of partition with partition-level deletion plus live rows in sstabledump (CASSANDRA-13177) http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb606dd4/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java -- diff --git a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java index acfa16b..1722f02 100644 --- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java +++ b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java @@ -657,6 +657,10 @@ public abstract class ModificationStatement implements CQLStatement { NavigableSet clusterings = createClustering(options); +// If some of the restrictions were unspecified (e.g. empty IN restrictions) we do not need to do anything. +if (restrictions.hasClusteringColumnsRestriction() && clusterings.isEmpty()) +return; + UpdateParameters params = makeUpdateParameters(keys, clusterings, options, local, now); for (ByteBuffer key : keys) http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb606dd4/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java -- diff --git a/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java b/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java index 18a6ca3..09098ac 100644 --- a/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java +++ b/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java @@ -28,11 +28,14 @@ import org.apache.commons.lang3.StringUtils; import org.junit.Test; import org.apache.cassandra.cql3.CQLTester; +import org.apache.cassandra.db.ColumnFamilyStore; +import org.apache.cassandra.db.Keyspace; import static org.apache.cassandra.utils.ByteBufferUtil.EMPTY_BYTE_BUFFER; import static org.apache.cassandra.utils.ByteBufferUtil.bytes; import static org.apache.commons.lang3.StringUtils.isEmpty; import static org.junit.Assert.assertEquals; +import static org.junit.Assert.assertTrue; public class DeleteTest extends CQLTester { @@ -1247,4 +1250,55 @@ public class DeleteTest extends CQLTester row(1, 1, 1, 3, 3), row(1, 1, 1, 4, 4)); } + +/** + * Test for CASSANDRA-13152 + */ +@Test +public void testThatDeletesWithEmptyInRestrictionDoNotCreateMutations() throws Throwable +{ +createTable("CREATE TABLE %s (a int, b int, c int, PRIMARY KEY (a,b))"); + +execute("DELETE FROM %s WHERE a IN ();"); +execute("DELETE FROM %s WHERE a IN () AND b IN ();"); +execute("DELETE FROM %s WHERE a IN () AND b = 1;"); +execute("DELETE FROM %s WHERE a = 1 AND b IN ();"); + +assertTrue("The memtable should be empty but is not", isMemtableEmpty()); + +createTable("CREATE TABLE %s (a int, b int, c int, d int, s int static, PRIMARY KEY ((a,b), c))"); + +execute("DELETE FROM %s WHERE a = 1 AND b = 1 AND c IN ();"); +execute("DELETE FROM %s WHERE a = 1 AND b IN () AND c IN ();"); +execute("DELETE FROM %s WHERE a IN () AND b IN () AND c IN ();"); +execute("
[3/3] cassandra git commit: Merge branch cassandra-3.11 into trunk
Merge branch cassandra-3.11 into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0564c8b4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0564c8b4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0564c8b4 Branch: refs/heads/trunk Commit: 0564c8b4225a6325613643a2b5c82e3390bee5c5 Parents: 98d74ed 3acdcaf Author: Benjamin Lerer Authored: Tue Feb 7 10:55:29 2017 +0100 Committer: Benjamin Lerer Committed: Tue Feb 7 10:55:29 2017 +0100 -- CHANGES.txt | 1 + .../cql3/statements/ModificationStatement.java | 4 ++ .../cql3/validation/operations/DeleteTest.java | 54 .../cql3/validation/operations/UpdateTest.java | 53 ++- 4 files changed, 110 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0564c8b4/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0564c8b4/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java --
[2/3] cassandra git commit: Merge branch cassandra-3.0 into cassandra-3.11
Merge branch cassandra-3.0 into cassandra-3.11 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3acdcaf8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3acdcaf8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3acdcaf8 Branch: refs/heads/trunk Commit: 3acdcaf8d3d3d5b959e4a14ac468d75d32b9177e Parents: 97861e6 fb606dd Author: Benjamin Lerer Authored: Tue Feb 7 10:42:20 2017 +0100 Committer: Benjamin Lerer Committed: Tue Feb 7 10:47:37 2017 +0100 -- CHANGES.txt | 1 + .../cql3/statements/ModificationStatement.java | 4 ++ .../cql3/validation/operations/DeleteTest.java | 54 .../cql3/validation/operations/UpdateTest.java | 54 ++-- 4 files changed, 110 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3acdcaf8/CHANGES.txt -- diff --cc CHANGES.txt index 65efebc,4387019..e346722 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,11 -1,6 +1,12 @@@ -3.0.11 +3.11.0 + * Move to FastThreadLocalThread and FastThreadLocal (CASSANDRA-13034) + * nodetool stopdaemon errors out (CASSANDRA-13030) + * Tables in system_distributed should not use gcgs of 0 (CASSANDRA-12954) + * Fix primary index calculation for SASI (CASSANDRA-12910) + * More fixes to the TokenAllocator (CASSANDRA-12990) + * NoReplicationTokenAllocator should work with zero replication factor (CASSANDRA-12983) +Merged from 3.0: + * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152) - * Abort or retry on failed hints delivery (CASSANDRA-13124) * Fix handling of partition with partition-level deletion plus live rows in sstabledump (CASSANDRA-13177) * Provide user workaround when system_schema.columns does not contain entries http://git-wip-us.apache.org/repos/asf/cassandra/blob/3acdcaf8/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java -- diff --cc src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java index 08bb6ba,1722f02..832d417 --- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java +++ b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java @@@ -661,7 -657,11 +661,11 @@@ public abstract class ModificationState { NavigableSet clusterings = createClustering(options); + // If some of the restrictions were unspecified (e.g. empty IN restrictions) we do not need to do anything. -if (restrictions.hasClusteringColumnsRestriction() && clusterings.isEmpty()) ++if (restrictions.hasClusteringColumnsRestrictions() && clusterings.isEmpty()) + return; + -UpdateParameters params = makeUpdateParameters(keys, clusterings, options, local, now); +UpdateParameters params = makeUpdateParameters(keys, clusterings, options, local, now, queryStartNanoTime); for (ByteBuffer key : keys) { http://git-wip-us.apache.org/repos/asf/cassandra/blob/3acdcaf8/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3acdcaf8/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java -- diff --cc test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java index 72d3466,a49f828..af6c4f9 --- a/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java +++ b/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java @@@ -23,14 -23,13 +23,16 @@@ import java.util.Arrays import org.junit.Assert; import org.junit.Test; --import static org.apache.commons.lang3.StringUtils.isEmpty; -import static org.junit.Assert.assertTrue; -- +import org.apache.cassandra.cql3.Attributes; import org.apache.cassandra.cql3.CQLTester; +import org.apache.cassandra.cql3.UntypedResultSet; +import org.apache.cassandra.cql3.UntypedResultSet.Row; - import org.apache.cassandra.utils.ByteBufferUtil; + import org.apache.cassandra.db.ColumnFamilyStore; + import org.apache.cassandra.db.Keyspace; + ++import static org.apache.commons.lang3.StringUtils.isEmpty; ++import static org.junit.Assert.assertTrue; + public class UpdateTest extends CQLTester { @Test
[2/2] cassandra git commit: Merge branch cassandra-3.0 into cassandra-3.11
Merge branch cassandra-3.0 into cassandra-3.11 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3acdcaf8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3acdcaf8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3acdcaf8 Branch: refs/heads/cassandra-3.11 Commit: 3acdcaf8d3d3d5b959e4a14ac468d75d32b9177e Parents: 97861e6 fb606dd Author: Benjamin Lerer Authored: Tue Feb 7 10:42:20 2017 +0100 Committer: Benjamin Lerer Committed: Tue Feb 7 10:47:37 2017 +0100 -- CHANGES.txt | 1 + .../cql3/statements/ModificationStatement.java | 4 ++ .../cql3/validation/operations/DeleteTest.java | 54 .../cql3/validation/operations/UpdateTest.java | 54 ++-- 4 files changed, 110 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3acdcaf8/CHANGES.txt -- diff --cc CHANGES.txt index 65efebc,4387019..e346722 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,11 -1,6 +1,12 @@@ -3.0.11 +3.11.0 + * Move to FastThreadLocalThread and FastThreadLocal (CASSANDRA-13034) + * nodetool stopdaemon errors out (CASSANDRA-13030) + * Tables in system_distributed should not use gcgs of 0 (CASSANDRA-12954) + * Fix primary index calculation for SASI (CASSANDRA-12910) + * More fixes to the TokenAllocator (CASSANDRA-12990) + * NoReplicationTokenAllocator should work with zero replication factor (CASSANDRA-12983) +Merged from 3.0: + * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152) - * Abort or retry on failed hints delivery (CASSANDRA-13124) * Fix handling of partition with partition-level deletion plus live rows in sstabledump (CASSANDRA-13177) * Provide user workaround when system_schema.columns does not contain entries http://git-wip-us.apache.org/repos/asf/cassandra/blob/3acdcaf8/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java -- diff --cc src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java index 08bb6ba,1722f02..832d417 --- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java +++ b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java @@@ -661,7 -657,11 +661,11 @@@ public abstract class ModificationState { NavigableSet clusterings = createClustering(options); + // If some of the restrictions were unspecified (e.g. empty IN restrictions) we do not need to do anything. -if (restrictions.hasClusteringColumnsRestriction() && clusterings.isEmpty()) ++if (restrictions.hasClusteringColumnsRestrictions() && clusterings.isEmpty()) + return; + -UpdateParameters params = makeUpdateParameters(keys, clusterings, options, local, now); +UpdateParameters params = makeUpdateParameters(keys, clusterings, options, local, now, queryStartNanoTime); for (ByteBuffer key : keys) { http://git-wip-us.apache.org/repos/asf/cassandra/blob/3acdcaf8/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3acdcaf8/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java -- diff --cc test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java index 72d3466,a49f828..af6c4f9 --- a/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java +++ b/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java @@@ -23,14 -23,13 +23,16 @@@ import java.util.Arrays import org.junit.Assert; import org.junit.Test; --import static org.apache.commons.lang3.StringUtils.isEmpty; -import static org.junit.Assert.assertTrue; -- +import org.apache.cassandra.cql3.Attributes; import org.apache.cassandra.cql3.CQLTester; +import org.apache.cassandra.cql3.UntypedResultSet; +import org.apache.cassandra.cql3.UntypedResultSet.Row; - import org.apache.cassandra.utils.ByteBufferUtil; + import org.apache.cassandra.db.ColumnFamilyStore; + import org.apache.cassandra.db.Keyspace; + ++import static org.apache.commons.lang3.StringUtils.isEmpty; ++import static org.junit.Assert.assertTrue; + public class UpdateTest extends CQLTester { @Test
[1/2] cassandra git commit: Fix UPDATE queries with empty IN restrictions
Repository: cassandra Updated Branches: refs/heads/cassandra-3.11 97861e68c -> 3acdcaf8d Fix UPDATE queries with empty IN restrictions patch by Benjamin Lerer; reviewed by Alex Petrov for CASSANDRA-13152 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fb606dd4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fb606dd4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fb606dd4 Branch: refs/heads/cassandra-3.11 Commit: fb606dd41c9f14324749efc1344421237c36a6db Parents: dab0e31 Author: Benjamin Lerer Authored: Tue Feb 7 10:35:48 2017 +0100 Committer: Benjamin Lerer Committed: Tue Feb 7 10:35:48 2017 +0100 -- CHANGES.txt | 1 + .../cql3/statements/ModificationStatement.java | 4 ++ .../cql3/validation/operations/DeleteTest.java | 54 .../cql3/validation/operations/UpdateTest.java | 53 ++- 4 files changed, 111 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb606dd4/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 1a90b1f..4387019 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.0.11 + * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152) * Abort or retry on failed hints delivery (CASSANDRA-13124) * Fix handling of partition with partition-level deletion plus live rows in sstabledump (CASSANDRA-13177) http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb606dd4/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java -- diff --git a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java index acfa16b..1722f02 100644 --- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java +++ b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java @@ -657,6 +657,10 @@ public abstract class ModificationStatement implements CQLStatement { NavigableSet clusterings = createClustering(options); +// If some of the restrictions were unspecified (e.g. empty IN restrictions) we do not need to do anything. +if (restrictions.hasClusteringColumnsRestriction() && clusterings.isEmpty()) +return; + UpdateParameters params = makeUpdateParameters(keys, clusterings, options, local, now); for (ByteBuffer key : keys) http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb606dd4/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java -- diff --git a/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java b/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java index 18a6ca3..09098ac 100644 --- a/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java +++ b/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java @@ -28,11 +28,14 @@ import org.apache.commons.lang3.StringUtils; import org.junit.Test; import org.apache.cassandra.cql3.CQLTester; +import org.apache.cassandra.db.ColumnFamilyStore; +import org.apache.cassandra.db.Keyspace; import static org.apache.cassandra.utils.ByteBufferUtil.EMPTY_BYTE_BUFFER; import static org.apache.cassandra.utils.ByteBufferUtil.bytes; import static org.apache.commons.lang3.StringUtils.isEmpty; import static org.junit.Assert.assertEquals; +import static org.junit.Assert.assertTrue; public class DeleteTest extends CQLTester { @@ -1247,4 +1250,55 @@ public class DeleteTest extends CQLTester row(1, 1, 1, 3, 3), row(1, 1, 1, 4, 4)); } + +/** + * Test for CASSANDRA-13152 + */ +@Test +public void testThatDeletesWithEmptyInRestrictionDoNotCreateMutations() throws Throwable +{ +createTable("CREATE TABLE %s (a int, b int, c int, PRIMARY KEY (a,b))"); + +execute("DELETE FROM %s WHERE a IN ();"); +execute("DELETE FROM %s WHERE a IN () AND b IN ();"); +execute("DELETE FROM %s WHERE a IN () AND b = 1;"); +execute("DELETE FROM %s WHERE a = 1 AND b IN ();"); + +assertTrue("The memtable should be empty but is not", isMemtableEmpty()); + +createTable("CREATE TABLE %s (a int, b int, c int, d int, s int static, PRIMARY KEY ((a,b), c))"); + +execute("DELETE FROM %s WHERE a = 1 AND b = 1 AND c IN ();"); +execute("DELETE FROM %s WHERE a = 1 AND b IN () AND c IN ();"); +execute("DELETE FROM %s WHERE a IN () AND b IN () AND c IN ();");
cassandra git commit: Fix UPDATE queries with empty IN restrictions
Repository: cassandra Updated Branches: refs/heads/cassandra-3.0 dab0e31ba -> fb606dd41 Fix UPDATE queries with empty IN restrictions patch by Benjamin Lerer; reviewed by Alex Petrov for CASSANDRA-13152 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fb606dd4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fb606dd4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fb606dd4 Branch: refs/heads/cassandra-3.0 Commit: fb606dd41c9f14324749efc1344421237c36a6db Parents: dab0e31 Author: Benjamin Lerer Authored: Tue Feb 7 10:35:48 2017 +0100 Committer: Benjamin Lerer Committed: Tue Feb 7 10:35:48 2017 +0100 -- CHANGES.txt | 1 + .../cql3/statements/ModificationStatement.java | 4 ++ .../cql3/validation/operations/DeleteTest.java | 54 .../cql3/validation/operations/UpdateTest.java | 53 ++- 4 files changed, 111 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb606dd4/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 1a90b1f..4387019 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.0.11 + * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152) * Abort or retry on failed hints delivery (CASSANDRA-13124) * Fix handling of partition with partition-level deletion plus live rows in sstabledump (CASSANDRA-13177) http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb606dd4/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java -- diff --git a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java index acfa16b..1722f02 100644 --- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java +++ b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java @@ -657,6 +657,10 @@ public abstract class ModificationStatement implements CQLStatement { NavigableSet clusterings = createClustering(options); +// If some of the restrictions were unspecified (e.g. empty IN restrictions) we do not need to do anything. +if (restrictions.hasClusteringColumnsRestriction() && clusterings.isEmpty()) +return; + UpdateParameters params = makeUpdateParameters(keys, clusterings, options, local, now); for (ByteBuffer key : keys) http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb606dd4/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java -- diff --git a/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java b/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java index 18a6ca3..09098ac 100644 --- a/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java +++ b/test/unit/org/apache/cassandra/cql3/validation/operations/DeleteTest.java @@ -28,11 +28,14 @@ import org.apache.commons.lang3.StringUtils; import org.junit.Test; import org.apache.cassandra.cql3.CQLTester; +import org.apache.cassandra.db.ColumnFamilyStore; +import org.apache.cassandra.db.Keyspace; import static org.apache.cassandra.utils.ByteBufferUtil.EMPTY_BYTE_BUFFER; import static org.apache.cassandra.utils.ByteBufferUtil.bytes; import static org.apache.commons.lang3.StringUtils.isEmpty; import static org.junit.Assert.assertEquals; +import static org.junit.Assert.assertTrue; public class DeleteTest extends CQLTester { @@ -1247,4 +1250,55 @@ public class DeleteTest extends CQLTester row(1, 1, 1, 3, 3), row(1, 1, 1, 4, 4)); } + +/** + * Test for CASSANDRA-13152 + */ +@Test +public void testThatDeletesWithEmptyInRestrictionDoNotCreateMutations() throws Throwable +{ +createTable("CREATE TABLE %s (a int, b int, c int, PRIMARY KEY (a,b))"); + +execute("DELETE FROM %s WHERE a IN ();"); +execute("DELETE FROM %s WHERE a IN () AND b IN ();"); +execute("DELETE FROM %s WHERE a IN () AND b = 1;"); +execute("DELETE FROM %s WHERE a = 1 AND b IN ();"); + +assertTrue("The memtable should be empty but is not", isMemtableEmpty()); + +createTable("CREATE TABLE %s (a int, b int, c int, d int, s int static, PRIMARY KEY ((a,b), c))"); + +execute("DELETE FROM %s WHERE a = 1 AND b = 1 AND c IN ();"); +execute("DELETE FROM %s WHERE a = 1 AND b IN () AND c IN ();"); +execute("DELETE FROM %s WHERE a IN () AND b IN () AND c IN ();"); +
[jira] [Created] (CASSANDRA-13189) Use prompt_toolkit in cqlsh
Corentin Chary created CASSANDRA-13189: -- Summary: Use prompt_toolkit in cqlsh Key: CASSANDRA-13189 URL: https://issues.apache.org/jira/browse/CASSANDRA-13189 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Corentin Chary Priority: Minor Attachments: cqlsh-prompt-tookit.png prompt_toolkit is an alternative to readline (https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a lot of software, including the upcomming version of ipython. I'm working on an initial version that keeps compatibility with readline, which is available here: https://github.com/iksaif/cassandra/tree/prompt_toolkit It's still missing tests and a few things, but I'm opening this for tracking and feedbacks. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (CASSANDRA-13189) Use prompt_toolkit in cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-13189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Corentin Chary reassigned CASSANDRA-13189: -- Assignee: Corentin Chary > Use prompt_toolkit in cqlsh > --- > > Key: CASSANDRA-13189 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13189 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Corentin Chary >Assignee: Corentin Chary >Priority: Minor > Attachments: cqlsh-prompt-tookit.png > > > prompt_toolkit is an alternative to readline > (https://github.com/jonathanslenders/python-prompt-toolkit) and is used in a > lot of software, including the upcomming version of ipython. > I'm working on an initial version that keeps compatibility with readline, > which is available here: > https://github.com/iksaif/cassandra/tree/prompt_toolkit > It's still missing tests and a few things, but I'm opening this for tracking > and feedbacks. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CASSANDRA-13187) Allow Filtering on Cluster Key columns while Partition Key is given
[ https://issues.apache.org/jira/browse/CASSANDRA-13187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-13187. -- Resolution: Not A Problem Fix Version/s: (was: 3.10) > Allow Filtering on Cluster Key columns while Partition Key is given > --- > > Key: CASSANDRA-13187 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13187 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Srini >Priority: Minor > > create table table1 ( > k_part_one text, > k_part_two int, > k_clust_one text, > k_clust_two int, > k_clust_three uuid, > data1 text, > data2 text, > PRIMARY KEY((k_part_one,k_part_two), k_clust_one, k_clust_two, > k_clust_three) > ); > select k_clust_one, k_clust_three , data1 > from table1 where k_part_one = ‘x’ and k_part_two = and > k_clust_two = allow filtering; > Allow filtering works on non primary key columns but it doesn't work on > clustering key columns for a given partition key. The above example skipped > k_clust_one and thus gives an error. > InvalidRequest: Error from server: code=2200 [Invalid query] message="PRIMARY > KEY column "k_clust_two" cannot be restricted as preceding column > "k_clust_one" is not restricted" > This is very similar to CASSANDRA-6377, CASSANDRA-11310, CASSANDRA -10715. > Yet, this is still unresolved. > This is very critical use case, where we want to avoid sending entire wide > row to the client and do filtering locally. It is an unnecessary network hog > that needs be avoided by doing the filtering on the actual Cassandra node. > Please note that there is no secondary index on this column family.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)