[jira] [Assigned] (CASSANDRA-12092) dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters
[ https://issues.apache.org/jira/browse/CASSANDRA-12092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefania reassigned CASSANDRA-12092: Assignee: Stefania (was: Sean McCarthy) > dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters > > > Key: CASSANDRA-12092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12092 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: Stefania > Labels: dtest > Attachments: node1.log, node2.log, node3.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_dtest/484/testReport/consistency_test/TestAccuracy/test_simple_strategy_counters > Failed on CassCI build cassandra-2.1_dtest #484 > {code} > Standard Error > Traceback (most recent call last): > File "/home/automaton/cassandra-dtest/consistency_test.py", line 514, in run > valid_fcn(v) > File "/home/automaton/cassandra-dtest/consistency_test.py", line 497, in > validate_counters > check_all_sessions(s, n, c) > File "/home/automaton/cassandra-dtest/consistency_test.py", line 490, in > check_all_sessions > "value of %s at key %d, instead got these values: %s" % (write_nodes, > val, n, results) > AssertionError: Failed to read value from sufficient number of nodes, > required 2 nodes to have a counter value of 1 at key 200, instead got these > values: [0, 0, 1] > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12092) dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters
[ https://issues.apache.org/jira/browse/CASSANDRA-12092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15413053#comment-15413053 ] Stefania commented on CASSANDRA-12092: -- Thank you for running the tests. There were no failures on 2.2, and 2 unrelated failures on trunk (it seems we still have schema agreement problems). For 2.1 there were 9 failures, all on key 200 except for 1, which was on key 598. Key 200 is the first key tested for the QUORUM/ONE/- range (200 to 249) whilst key 598 refers to the TWO/ONE/- range (550 to 599). So it seems this problem affects 2.1 only, I'm going to take a look. > dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters > > > Key: CASSANDRA-12092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12092 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: Sean McCarthy > Labels: dtest > Attachments: node1.log, node2.log, node3.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_dtest/484/testReport/consistency_test/TestAccuracy/test_simple_strategy_counters > Failed on CassCI build cassandra-2.1_dtest #484 > {code} > Standard Error > Traceback (most recent call last): > File "/home/automaton/cassandra-dtest/consistency_test.py", line 514, in run > valid_fcn(v) > File "/home/automaton/cassandra-dtest/consistency_test.py", line 497, in > validate_counters > check_all_sessions(s, n, c) > File "/home/automaton/cassandra-dtest/consistency_test.py", line 490, in > check_all_sessions > "value of %s at key %d, instead got these values: %s" % (write_nodes, > val, n, results) > AssertionError: Failed to read value from sufficient number of nodes, > required 2 nodes to have a counter value of 1 at key 200, instead got these > values: [0, 0, 1] > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11521) Implement streaming for bulk read requests
[ https://issues.apache.org/jira/browse/CASSANDRA-11521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefania updated CASSANDRA-11521: - Status: Patch Available (was: In Progress) > Implement streaming for bulk read requests > -- > > Key: CASSANDRA-11521 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11521 > Project: Cassandra > Issue Type: Sub-task > Components: Local Write-Read Paths >Reporter: Stefania >Assignee: Stefania > Labels: client-impacting, protocolv5 > Fix For: 3.x > > Attachments: final-patch-jfr-profiles-1.zip > > > Allow clients to stream data from a C* host, bypassing the coordination layer > and eliminating the need to query individual pages one by one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11521) Implement streaming for bulk read requests
[ https://issues.apache.org/jira/browse/CASSANDRA-11521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15413016#comment-15413016 ] Stefania commented on CASSANDRA-11521: -- Rebase completed, tests are fine: ||trunk|[patch|https://github.com/stef1927/cassandra/commits/11521]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11521-testall/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11521-dtest/]| I've also linked this new feature to version 5 of the native protocol and added support for it to the Java driver. > Implement streaming for bulk read requests > -- > > Key: CASSANDRA-11521 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11521 > Project: Cassandra > Issue Type: Sub-task > Components: Local Write-Read Paths >Reporter: Stefania >Assignee: Stefania > Labels: client-impacting, protocolv5 > Fix For: 3.x > > Attachments: final-patch-jfr-profiles-1.zip > > > Allow clients to stream data from a C* host, bypassing the coordination layer > and eliminating the need to query individual pages one by one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: remove dead parm 'isDense', obsoleted by 9c3855b
Repository: cassandra Updated Branches: refs/heads/trunk 0565690de -> 2c4b30164 remove dead parm 'isDense', obsoleted by 9c3855b Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2c4b3016 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2c4b3016 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2c4b3016 Branch: refs/heads/trunk Commit: 2c4b3016413de3f329c8128b138827f828c86dd0 Parents: 0565690 Author: Dave Brosius Authored: Mon Aug 8 22:57:19 2016 -0400 Committer: Dave Brosius Committed: Mon Aug 8 22:57:19 2016 -0400 -- .../apache/cassandra/cql3/SingleColumnRelation.java | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/2c4b3016/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java -- diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java index 1565102..22df6bd 100644 --- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java +++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java @@ -161,10 +161,10 @@ public final class SingleColumnRelation extends Relation ColumnDefinition columnDef = entity.prepare(cfm); if (mapKey == null) { -Term term = toTerm(toReceivers(columnDef, cfm.isDense()), value, cfm.ksName, boundNames); +Term term = toTerm(toReceivers(columnDef), value, cfm.ksName, boundNames); return new SingleColumnRestriction.EQRestriction(columnDef, term); } -List receivers = toReceivers(columnDef, cfm.isDense()); +List receivers = toReceivers(columnDef); Term entryKey = toTerm(Collections.singletonList(receivers.get(0)), mapKey, cfm.ksName, boundNames); Term entryValue = toTerm(Collections.singletonList(receivers.get(1)), value, cfm.ksName, boundNames); return new SingleColumnRestriction.ContainsRestriction(columnDef, entryKey, entryValue); @@ -175,7 +175,7 @@ public final class SingleColumnRelation extends Relation VariableSpecifications boundNames) throws InvalidRequestException { ColumnDefinition columnDef = entity.prepare(cfm); -List receivers = toReceivers(columnDef, cfm.isDense()); +List receivers = toReceivers(columnDef); List terms = toTerms(receivers, inValues, cfm.ksName, boundNames); if (terms == null) { @@ -197,7 +197,7 @@ public final class SingleColumnRelation extends Relation boolean inclusive) throws InvalidRequestException { ColumnDefinition columnDef = entity.prepare(cfm); -Term term = toTerm(toReceivers(columnDef, cfm.isDense()), value, cfm.ksName, boundNames); +Term term = toTerm(toReceivers(columnDef), value, cfm.ksName, boundNames); return new SingleColumnRestriction.SliceRestriction(columnDef, bound, inclusive, term); } @@ -207,7 +207,7 @@ public final class SingleColumnRelation extends Relation boolean isKey) throws InvalidRequestException { ColumnDefinition columnDef = entity.prepare(cfm); -Term term = toTerm(toReceivers(columnDef, cfm.isDense()), value, cfm.ksName, boundNames); +Term term = toTerm(toReceivers(columnDef), value, cfm.ksName, boundNames); return new SingleColumnRestriction.ContainsRestriction(columnDef, term, isKey); } @@ -228,7 +228,7 @@ public final class SingleColumnRelation extends Relation throw invalidRequest("%s can't be used with collections.", operator()); ColumnDefinition columnDef = entity.prepare(cfm); -Term term = toTerm(toReceivers(columnDef, cfm.isDense()), value, cfm.ksName, boundNames); +Term term = toTerm(toReceivers(columnDef), value, cfm.ksName, boundNames); return new SingleColumnRestriction.LikeRestriction(columnDef, operator, term); } @@ -236,12 +236,10 @@ public final class SingleColumnRelation extends Relation /** * Returns the receivers for this relation. * @param columnDef the column definition - * @param isDense whether the table is a dense one - * * @return the receivers for the specified relation. * @throws InvalidRequestException if the relation is invalid */ -private List toReceivers(ColumnDefinition columnDef, boolean isDense) throws InvalidRequestException +private List toReceivers(ColumnDefinition columnDef) throws InvalidRequestException { ColumnSpecification receiver = columnDef;
[jira] [Commented] (CASSANDRA-11990) Address rows rather than partitions in SASI
[ https://issues.apache.org/jira/browse/CASSANDRA-11990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412775#comment-15412775 ] Pavel Yaskevich commented on CASSANDRA-11990: - I looked at the code again and I think we might be better off keeping only Murmur3Partitioner (tokens as longs) for now instead of changing so much just to support RP... That would also make update path much easier for us - a. added clustering positions, b. extend tokens sizes to variable size. instead of having intermediate of multi-size fixed tokens... *Code remarks:* - https://github.com/apache/cassandra/compare/trunk...ifesdjeen:11990-trunk#diff-2143dfad950ab134c0a25bd903c2875aR143 what is the point of logger.info it it's still wrapped into logger.isDebugEnabled() ? - Can you move drop-data and rebuild related changes to the separate branch so we can keep changes to token tree and bug fixes separate since they are separate tickets? https://github.com/apache/cassandra/compare/trunk...ifesdjeen:11990-trunk#diff-afe204f22033543e3ae0185240523a9bR113 I'm not sure what is this `// ignore` about?... - SasiToken -> SASIToken since SASI is an abbreviation already. - Back to the point about not supporting PR; the way TokenTreeSerializationHelper is currently done is not optimal since it has to be explicitly carried around, which means that it's most likely not a proper abstraction to have, e.g. higher levels like QueryPlan/Operation/Expression/ColumnIndex should never care about any details about TokenTree, especially about how it's tokens are serialized, we should either use IPartitioner interface or nothing at all. - Upgrade test is missing for TokenTree. > Address rows rather than partitions in SASI > --- > > Key: CASSANDRA-11990 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11990 > Project: Cassandra > Issue Type: Improvement > Components: CQL, sasi >Reporter: Alex Petrov >Assignee: Alex Petrov > Attachments: perf.pdf, size_comparison.png > > > Currently, the lookup in SASI index would return the key position of the > partition. After the partition lookup, the rows are iterated and the > operators are applied in order to filter out ones that do not match. > bq. TokenTree which accepts variable size keys (such would enable different > partitioners, collections support, primary key indexing etc.), -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11990) Address rows rather than partitions in SASI
[ https://issues.apache.org/jira/browse/CASSANDRA-11990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412775#comment-15412775 ] Pavel Yaskevich edited comment on CASSANDRA-11990 at 8/9/16 1:12 AM: - I looked at the code again and I think we might be better off keeping only Murmur3Partitioner (tokens as longs) for now instead of changing so much just to support RP... That would also make update path much easier for us - a. added clustering positions, b. extend tokens sizes to variable size. instead of having intermediate of multi-size fixed tokens... *Code remarks:* - https://github.com/apache/cassandra/compare/trunk...ifesdjeen:11990-trunk#diff-2143dfad950ab134c0a25bd903c2875aR143 what is the point of logger.info it it's still wrapped into logger.isDebugEnabled() ? - Can you move drop-data and rebuild related changes to the separate branch so we can keep changes to token tree and bug fixes separate since they are separate tickets? - https://github.com/apache/cassandra/compare/trunk...ifesdjeen:11990-trunk#diff-afe204f22033543e3ae0185240523a9bR113 I'm not sure what is this `// ignore` about?... - SasiToken -> SASIToken since SASI is an abbreviation already. - Back to the point about not supporting PR; the way TokenTreeSerializationHelper is currently done is not optimal since it has to be explicitly carried around, which means that it's most likely not a proper abstraction to have, e.g. higher levels like QueryPlan/Operation/Expression/ColumnIndex should never care about any details about TokenTree, especially about how it's tokens are serialized, we should either use IPartitioner interface or nothing at all. - Upgrade test is missing for TokenTree. was (Author: xedin): I looked at the code again and I think we might be better off keeping only Murmur3Partitioner (tokens as longs) for now instead of changing so much just to support RP... That would also make update path much easier for us - a. added clustering positions, b. extend tokens sizes to variable size. instead of having intermediate of multi-size fixed tokens... *Code remarks:* - https://github.com/apache/cassandra/compare/trunk...ifesdjeen:11990-trunk#diff-2143dfad950ab134c0a25bd903c2875aR143 what is the point of logger.info it it's still wrapped into logger.isDebugEnabled() ? - Can you move drop-data and rebuild related changes to the separate branch so we can keep changes to token tree and bug fixes separate since they are separate tickets? https://github.com/apache/cassandra/compare/trunk...ifesdjeen:11990-trunk#diff-afe204f22033543e3ae0185240523a9bR113 I'm not sure what is this `// ignore` about?... - SasiToken -> SASIToken since SASI is an abbreviation already. - Back to the point about not supporting PR; the way TokenTreeSerializationHelper is currently done is not optimal since it has to be explicitly carried around, which means that it's most likely not a proper abstraction to have, e.g. higher levels like QueryPlan/Operation/Expression/ColumnIndex should never care about any details about TokenTree, especially about how it's tokens are serialized, we should either use IPartitioner interface or nothing at all. - Upgrade test is missing for TokenTree. > Address rows rather than partitions in SASI > --- > > Key: CASSANDRA-11990 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11990 > Project: Cassandra > Issue Type: Improvement > Components: CQL, sasi >Reporter: Alex Petrov >Assignee: Alex Petrov > Attachments: perf.pdf, size_comparison.png > > > Currently, the lookup in SASI index would return the key position of the > partition. After the partition lookup, the rows are iterated and the > operators are applied in order to filter out ones that do not match. > bq. TokenTree which accepts variable size keys (such would enable different > partitioners, collections support, primary key indexing etc.), -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11701) [windows] dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_reading_with_skip_and_max_rows
[ https://issues.apache.org/jira/browse/CASSANDRA-11701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412744#comment-15412744 ] Stefania commented on CASSANDRA-11701: -- I cannot reproduce the build abort in Windows: build [#10|http://cassci.datastax.com/job/stef1927-dtest-multiplex-win32/10], [#11|http://cassci.datastax.com/job/stef1927-dtest-multiplex-win32/11/] and [#12|http://cassci.datastax.com/job/stef1927-dtest-multiplex-win32/12/] are all without failures, each build ran the cqlsh copy tests 5 times. So moving to patch available. > [windows] dtest failure in > cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_reading_with_skip_and_max_rows > - > > Key: CASSANDRA-11701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11701 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: Stefania > Labels: dtest, windows > > looks to be an assertion problem, so could be test or cassandra related: > e.g.: > {noformat} > 1 != 331 > {noformat} > http://cassci.datastax.com/job/trunk_dtest_win32/404/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_reading_with_skip_and_max_rows > Failed on CassCI build trunk_dtest_win32 #404 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11701) [windows] dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_reading_with_skip_and_max_rows
[ https://issues.apache.org/jira/browse/CASSANDRA-11701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefania updated CASSANDRA-11701: - Status: Patch Available (was: In Progress) > [windows] dtest failure in > cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_reading_with_skip_and_max_rows > - > > Key: CASSANDRA-11701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11701 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: Stefania > Labels: dtest, windows > > looks to be an assertion problem, so could be test or cassandra related: > e.g.: > {noformat} > 1 != 331 > {noformat} > http://cassci.datastax.com/job/trunk_dtest_win32/404/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_reading_with_skip_and_max_rows > Failed on CassCI build trunk_dtest_win32 #404 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12407) dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412717#comment-15412717 ] Stefania commented on CASSANDRA-12407: -- The problem is that we haven't received the tracing events from non-coordinator replicas. The fix was delivered by CASSANDRA-11465 but it only went into 2.2+. We can either skip the test in 2.1 or change the regex in the test and remove the forward slash from the IP address if the version is less than 2.2. > dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test > > > Key: CASSANDRA-12407 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12407 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: Philip Thompson > Labels: dtest > Attachments: node1.log, node2.log, node3.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/381/testReport/cql_tracing_test/TestCqlTracing/tracing_simple_test > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 102, in > tracing_simple_test > self.trace(session) > File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 74, in > trace > self.assertIn('/127.0.0.1', out) > File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn > self.fail(self._formatMessage(msg, standardMsg)) > File "/usr/lib/python2.7/unittest/case.py", line 410, in fail > raise self.failureException(msg) > '\'/127.0.0.1\' not found in "Consistency level set to ALL. > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12008) Make decommission operations resumable
[ https://issues.apache.org/jira/browse/CASSANDRA-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412708#comment-15412708 ] Kaide Mu commented on CASSANDRA-12008: -- I've opened a pr: https://github.com/riptano/cassandra-dtest/pull/1192 > Make decommission operations resumable > -- > > Key: CASSANDRA-12008 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12008 > Project: Cassandra > Issue Type: Improvement > Components: Streaming and Messaging >Reporter: Tom van der Woerdt >Assignee: Kaide Mu >Priority: Minor > > We're dealing with large data sets (multiple terabytes per node) and > sometimes we need to add or remove nodes. These operations are very dependent > on the entire cluster being up, so while we're joining a new node (which > sometimes takes 6 hours or longer) a lot can go wrong and in a lot of cases > something does. > It would be great if the ability to retry streams was implemented. > Example to illustrate the problem : > {code} > 03:18 PM ~ $ nodetool decommission > error: Stream failed > -- StackTrace -- > org.apache.cassandra.streaming.StreamException: Stream failed > at > org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85) > at com.google.common.util.concurrent.Futures$6.run(Futures.java:1310) > at > com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457) > at > com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156) > at > com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145) > at > com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202) > at > org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:210) > at > org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:186) > at > org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:430) > at > org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:622) > at > org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:486) > at > org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:274) > at java.lang.Thread.run(Thread.java:745) > 08:04 PM ~ $ nodetool decommission > nodetool: Unsupported operation: Node in LEAVING state; wait for status to > become normal or restart > See 'nodetool help' or 'nodetool help '. > {code} > Streaming failed, probably due to load : > {code} > ERROR [STREAM-IN-/] 2016-06-14 18:05:47,275 StreamSession.java:520 - > [Stream #] Streaming error occurred > java.net.SocketTimeoutException: null > at > sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:211) > ~[na:1.8.0_77] > at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) > ~[na:1.8.0_77] > at > java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:385) > ~[na:1.8.0_77] > at > org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:54) > ~[apache-cassandra-3.0.6.jar:3.0.6] > at > org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:268) > ~[apache-cassandra-3.0.6.jar:3.0.6] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_77] > {code} > If implementing retries is not possible, can we have a 'nodetool decommission > resume'? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12311) Propagate TombstoneOverwhelmingException to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-12311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey Yu updated CASSANDRA-12311: Attachment: 12311-dtest.txt Thanks for the help with the driver and the example test! I really appreciate it. :) I've attached a patch meant to be applied on top of your {{CASSANDRA-12311-tests}} branch. It modifies {{paging_test.py:TestPagingWithDeletions.test_failure_threshold_deletions}} and {{write_failure_tests.py}} so that they check for the failure map when protocol v5 is used. I also added another file, {{read_failure_tests.py}} to test read failures due to reading too many tombstones. I modeled it after {{write_failure_tests.py}} and added tests for protocol v3 and v4 as well. > Propagate TombstoneOverwhelmingException to the client > -- > > Key: CASSANDRA-12311 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12311 > Project: Cassandra > Issue Type: Improvement >Reporter: Geoffrey Yu >Assignee: Geoffrey Yu >Priority: Minor > Labels: client-impacting, doc-impacting > Fix For: 4.x > > Attachments: 12311-dtest.txt, 12311-trunk-v2.txt, 12311-trunk-v3.txt, > 12311-trunk-v4.txt, 12311-trunk-v5.txt, 12311-trunk.txt > > > Right now if a data node fails to perform a read because it ran into a > {{TombstoneOverwhelmingException}}, it only responds back to the coordinator > node with a generic failure. Under this scheme, the coordinator won't be able > to know exactly why the request failed and subsequently the client only gets > a generic {{ReadFailureException}}. It would be useful to inform the client > that their read failed because we read too many tombstones. We should have > the data nodes reply with a failure type so the coordinator can pass this > information to the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12414) dtest failure in ttl_test.TestDistributedTTL.ttl_is_respected_on_delayed_replication_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12414: Description: example failure: http://cassci.datastax.com/job/cassandra-3.9_dtest/31/testReport/ttl_test/TestDistributedTTL/ttl_is_respected_on_delayed_replication_test {code} File "/usr/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/home/automaton/cassandra-dtest/ttl_test.py", line 439, in ttl_is_respected_on_delayed_replication_test self.assertLessEqual(abs(ttl_session1[0][0] - ttl_session2[0][0]), 1) "unsupported operand type(s) for -: 'NoneType' and 'int' {code} was: example failure: http://cassci.datastax.com/job/cassandra-3.9_dtest/lastCompletedBuild/testReport/ttl_test/TestDistributedTTL/ttl_is_respected_on_delayed_replication_test {code} File "/usr/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/home/automaton/cassandra-dtest/ttl_test.py", line 439, in ttl_is_respected_on_delayed_replication_test self.assertLessEqual(abs(ttl_session1[0][0] - ttl_session2[0][0]), 1) "unsupported operand type(s) for -: 'NoneType' and 'int' {code} > dtest failure in > ttl_test.TestDistributedTTL.ttl_is_respected_on_delayed_replication_test > - > > Key: CASSANDRA-12414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12414 > Project: Cassandra > Issue Type: Test >Reporter: Philip Thompson >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_dtest/31/testReport/ttl_test/TestDistributedTTL/ttl_is_respected_on_delayed_replication_test > {code} > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/ttl_test.py", line 439, in > ttl_is_respected_on_delayed_replication_test > self.assertLessEqual(abs(ttl_session1[0][0] - ttl_session2[0][0]), 1) > "unsupported operand type(s) for -: 'NoneType' and 'int' > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12415) dtest failure in replace_address_test.TestReplaceAddress.replace_stopped_node_test
Philip Thompson created CASSANDRA-12415: --- Summary: dtest failure in replace_address_test.TestReplaceAddress.replace_stopped_node_test Key: CASSANDRA-12415 URL: https://issues.apache.org/jira/browse/CASSANDRA-12415 Project: Cassandra Issue Type: Test Reporter: Philip Thompson Assignee: DS Test Eng example failure: http://cassci.datastax.com/job/cassandra-3.9_dtest/31/testReport/replace_address_test/TestReplaceAddress/replace_stopped_node_test Node4 just doesn't start up in time. Maybe bump up the timeout, or move to large test? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12358) Slow PostFlush execution due to 2i flushing can cause near OOM to OOM
[ https://issues.apache.org/jira/browse/CASSANDRA-12358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412576#comment-15412576 ] Ariel Weisberg commented on CASSANDRA-12358: Double blue! Hats off to the C* team that is awesome. > Slow PostFlush execution due to 2i flushing can cause near OOM to OOM > - > > Key: CASSANDRA-12358 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12358 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Fix For: 3.10 > > > 2i can be slow to flush for a variety of reasons. Potentially slower than the > rate at which Memtables can ingest and flush data. If this occurs the heap > fills up with Memtables that are waiting for PostFlush to run. > This occurs because reclaiming the memory is done before PostFlush runs. > I will post a branch that has the reclaim memory task run after PostFlush has > completed. As far as I can tell this is safe and correct since the memory is > committed up until that point. > It's not clear to me if PostFlush has to bind the Memtables or not. I suspect > it does, but I'm not sure if that is a route I should go down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12414) dtest failure in ttl_test.TestDistributedTTL.ttl_is_respected_on_delayed_replication_test
Philip Thompson created CASSANDRA-12414: --- Summary: dtest failure in ttl_test.TestDistributedTTL.ttl_is_respected_on_delayed_replication_test Key: CASSANDRA-12414 URL: https://issues.apache.org/jira/browse/CASSANDRA-12414 Project: Cassandra Issue Type: Test Reporter: Philip Thompson Assignee: DS Test Eng example failure: http://cassci.datastax.com/job/cassandra-3.9_dtest/lastCompletedBuild/testReport/ttl_test/TestDistributedTTL/ttl_is_respected_on_delayed_replication_test {code} File "/usr/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/home/automaton/cassandra-dtest/ttl_test.py", line 439, in ttl_is_respected_on_delayed_replication_test self.assertLessEqual(abs(ttl_session1[0][0] - ttl_session2[0][0]), 1) "unsupported operand type(s) for -: 'NoneType' and 'int' {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12249) dtest failure in upgrade_tests.paging_test.TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_x.basic_paging_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412558#comment-15412558 ] Joshua McKenzie commented on CASSANDRA-12249: - [~blerer]: Any chance you can take a look at this soon? This is causing quite a few upgrade test failures. > dtest failure in > upgrade_tests.paging_test.TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_x.basic_paging_test > --- > > Key: CASSANDRA-12249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12249 > Project: Cassandra > Issue Type: Bug >Reporter: Philip Thompson >Assignee: Benjamin Lerer > Labels: dtest > Fix For: 3.x > > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log > > > example failure: > http://cassci.datastax.com/job/cassandra-3.8_dtest_upgrade/1/testReport/upgrade_tests.paging_test/TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_x/basic_paging_test > Failed on CassCI build cassandra-3.8_dtest_upgrade #1 > This is on a mixed version cluster, one node is 3.0.8 and the other is > 3.8-tentative. > Stack trace looks like: > {code} > ERROR [MessagingService-Incoming-/127.0.0.1] 2016-07-20 04:51:02,836 > CassandraDaemon.java:201 - Exception in thread > Thread[MessagingService-Incoming-/127.0.0.1,5,main] > java.lang.AssertionError: null > at > org.apache.cassandra.db.ReadCommand$LegacyPagedRangeCommandSerializer.deserialize(ReadCommand.java:1042) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.db.ReadCommand$LegacyPagedRangeCommandSerializer.deserialize(ReadCommand.java:964) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at org.apache.cassandra.net.MessageIn.read(MessageIn.java:98) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:201) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:178) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:92) > ~[apache-cassandra-3.0.8.jar:3.0.8] > {code} > This trace is from the 3.0.8 node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12411) Do not store passwords in .cassandra/cqlsh_history
[ https://issues.apache.org/jira/browse/CASSANDRA-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412536#comment-15412536 ] Daniel Cohen commented on CASSANDRA-12411: -- [~snazy] That sounds like a potentially hard or inherently incomplete (meaning, unsafe) problem. Perhaps I am wrong, or perhaps there is another way to look at it? If we break it into two parts, as you would on the command line, it would be easy to never log the inserted password part. > Do not store passwords in .cassandra/cqlsh_history > -- > > Key: CASSANDRA-12411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12411 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: jonathan lacefield > > This is a request to ensure that passwords are not stored in the > cqlsh_history file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12413) CompactionsCQLTest.testTriggerMinorCompactionDTCS fails
Joshua McKenzie created CASSANDRA-12413: --- Summary: CompactionsCQLTest.testTriggerMinorCompactionDTCS fails Key: CASSANDRA-12413 URL: https://issues.apache.org/jira/browse/CASSANDRA-12413 Project: Cassandra Issue Type: Bug Reporter: Joshua McKenzie Assignee: Marcus Eriksson [Link|http://cassci.datastax.com/job/cassandra-3.9_testall/lastCompletedBuild/testReport/org.apache.cassandra.db.compaction/CompactionsCQLTest/testTriggerMinorCompactionDTCS/] Error Message No minor compaction triggered in 5000ms Stacktrace {noformat} junit.framework.AssertionFailedError: No minor compaction triggered in 5000ms at org.apache.cassandra.db.compaction.CompactionsCQLTest.waitForMinor(CompactionsCQLTest.java:247) at org.apache.cassandra.db.compaction.CompactionsCQLTest.testTriggerMinorCompactionDTCS(CompactionsCQLTest.java:72) {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12411) Do not store passwords in .cassandra/cqlsh_history
[ https://issues.apache.org/jira/browse/CASSANDRA-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412524#comment-15412524 ] Robert Stupp commented on CASSANDRA-12411: -- Again, the problem is how should such a regex look like to also catch typos {{CREATE USER foo WITG PASSWORT 'bar'}}. > Do not store passwords in .cassandra/cqlsh_history > -- > > Key: CASSANDRA-12411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12411 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: jonathan lacefield > > This is a request to ensure that passwords are not stored in the > cqlsh_history file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12411) Do not store passwords in .cassandra/cqlsh_history
[ https://issues.apache.org/jira/browse/CASSANDRA-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412515#comment-15412515 ] Brad Vernon commented on CASSANDRA-12411: - Couldn't cqlsh just ignore for those cql commands that use the pattern "WITH PASSWORD '.*'" and if matched via RegEx don't store in the history or replace with the common *. It would only match on CREATE USER, ALTER USER and CREATE ROLE commands. If using a standard non-User/role based command like INSERT or UPDATE logging would make sense since there is no understanding that the command being run is specific to a C* User's login, but in the above cases it's known. > Do not store passwords in .cassandra/cqlsh_history > -- > > Key: CASSANDRA-12411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12411 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: jonathan lacefield > > This is a request to ensure that passwords are not stored in the > cqlsh_history file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10848) Upgrade paging dtests involving deletion flap on CassCI
[ https://issues.apache.org/jira/browse/CASSANDRA-10848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412448#comment-15412448 ] Russ Hatch commented on CASSANDRA-10848: I think of the remaining failures, a large number (maybe all) can be attributed to CASSANDRA-12249. I'd like to keep this open until 12249 is resolved, but that combined with the proto v4 test fixes might have us in pretty good shape with these tests. > Upgrade paging dtests involving deletion flap on CassCI > --- > > Key: CASSANDRA-10848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10848 > Project: Cassandra > Issue Type: Bug >Reporter: Jim Witschey >Assignee: Russ Hatch > Labels: dtest > Fix For: 3.0.x, 3.x > > > A number of dtests in the {{upgrade_tests.paging_tests}} that involve > deletion flap with the following error: > {code} > Requested pages were not delivered before timeout. > {code} > This may just be an effect of CASSANDRA-10730, but it's worth having a look > at separately. Here are some examples of tests flapping in this way: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12249) dtest failure in upgrade_tests.paging_test.TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_x.basic_paging_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412433#comment-15412433 ] Russ Hatch commented on CASSANDRA-12249: This issue appears to be the root cause of a number of CI test failures on the upgrade suites. > dtest failure in > upgrade_tests.paging_test.TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_x.basic_paging_test > --- > > Key: CASSANDRA-12249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12249 > Project: Cassandra > Issue Type: Bug >Reporter: Philip Thompson >Assignee: Benjamin Lerer > Labels: dtest > Fix For: 3.x > > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log > > > example failure: > http://cassci.datastax.com/job/cassandra-3.8_dtest_upgrade/1/testReport/upgrade_tests.paging_test/TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_x/basic_paging_test > Failed on CassCI build cassandra-3.8_dtest_upgrade #1 > This is on a mixed version cluster, one node is 3.0.8 and the other is > 3.8-tentative. > Stack trace looks like: > {code} > ERROR [MessagingService-Incoming-/127.0.0.1] 2016-07-20 04:51:02,836 > CassandraDaemon.java:201 - Exception in thread > Thread[MessagingService-Incoming-/127.0.0.1,5,main] > java.lang.AssertionError: null > at > org.apache.cassandra.db.ReadCommand$LegacyPagedRangeCommandSerializer.deserialize(ReadCommand.java:1042) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.db.ReadCommand$LegacyPagedRangeCommandSerializer.deserialize(ReadCommand.java:964) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at org.apache.cassandra.net.MessageIn.read(MessageIn.java:98) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:201) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:178) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:92) > ~[apache-cassandra-3.0.8.jar:3.0.8] > {code} > This trace is from the 3.0.8 node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12249) dtest failure in upgrade_tests.paging_test.TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_x.basic_paging_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412381#comment-15412381 ] Russ Hatch commented on CASSANDRA-12249: I can get this consistently with: {noformat}nosetests -v upgrade_tests/paging_test.py:TestPagingDataNodes3RF3_Upgrade_current_3_x_To_indev_3_x.test_paging_using_secondary_indexes{noformat} For that particular test, I can see that the first page of results appears to be returned, but the remaining pages aren't. > dtest failure in > upgrade_tests.paging_test.TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_x.basic_paging_test > --- > > Key: CASSANDRA-12249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12249 > Project: Cassandra > Issue Type: Bug >Reporter: Philip Thompson >Assignee: Benjamin Lerer > Labels: dtest > Fix For: 3.x > > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log > > > example failure: > http://cassci.datastax.com/job/cassandra-3.8_dtest_upgrade/1/testReport/upgrade_tests.paging_test/TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_x/basic_paging_test > Failed on CassCI build cassandra-3.8_dtest_upgrade #1 > This is on a mixed version cluster, one node is 3.0.8 and the other is > 3.8-tentative. > Stack trace looks like: > {code} > ERROR [MessagingService-Incoming-/127.0.0.1] 2016-07-20 04:51:02,836 > CassandraDaemon.java:201 - Exception in thread > Thread[MessagingService-Incoming-/127.0.0.1,5,main] > java.lang.AssertionError: null > at > org.apache.cassandra.db.ReadCommand$LegacyPagedRangeCommandSerializer.deserialize(ReadCommand.java:1042) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.db.ReadCommand$LegacyPagedRangeCommandSerializer.deserialize(ReadCommand.java:964) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at org.apache.cassandra.net.MessageIn.read(MessageIn.java:98) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:201) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:178) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:92) > ~[apache-cassandra-3.0.8.jar:3.0.8] > {code} > This trace is from the 3.0.8 node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11031) MultiTenant : support “ALLOW FILTERING" for Partition Key
[ https://issues.apache.org/jira/browse/CASSANDRA-11031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412344#comment-15412344 ] Benjamin Lerer commented on CASSANDRA-11031: I will have a look as soon as I can (probably next week). > MultiTenant : support “ALLOW FILTERING" for Partition Key > - > > Key: CASSANDRA-11031 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11031 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Minor > Fix For: 3.x > > Attachments: CASSANDRA-11031-3.7.patch > > > Currently, Allow Filtering only works for secondary Index column or > clustering columns. And it's slow, because Cassandra will read all data from > SSTABLE from hard-disk to memory to filter. > But we can support allow filtering on Partition Key, as far as I know, > Partition Key is in memory, so we can easily filter them, and then read > required data from SSTable. > This will similar to "Select * from table" which scan through entire cluster. > CREATE TABLE multi_tenant_table ( > tenant_id text, > pk2 text, > c1 text, > c2 text, > v1 text, > v2 text, > PRIMARY KEY ((tenant_id,pk2),c1,c2) > ) ; > Select * from multi_tenant_table where tenant_id = "datastax" allow filtering; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12176) dtest failure in materialized_views_test.TestMaterializedViews.complex_repair_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412322#comment-15412322 ] Philip Thompson commented on CASSANDRA-12176: - I'd be okay closing, as we can always re-open if we see it again, but it's up to Carl. > dtest failure in > materialized_views_test.TestMaterializedViews.complex_repair_test > -- > > Key: CASSANDRA-12176 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12176 > Project: Cassandra > Issue Type: Bug >Reporter: Sean McCarthy >Assignee: Carl Yeksigian > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log, > node4.log, node4_debug.log, node4_gc.log, node5.log, node5_debug.log, > node5_gc.log > > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/8/testReport/materialized_views_test/TestMaterializedViews/complex_repair_test > Failed on CassCI build cassandra-3.9_novnode_dtest #8 > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/materialized_views_test.py", line > 956, in complex_repair_test > session.execute("CREATE TABLE ks.t (id int PRIMARY KEY, v int, v2 text, > v3 decimal)" > File "cassandra/cluster.py", line 1941, in > cassandra.cluster.Session.execute (cassandra/cluster.c:33642) > return self.execute_async(query, parameters, trace, custom_payload, > timeout, execution_profile).result() > File "cassandra/cluster.py", line 3629, in > cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69369) > raise self._final_exception > ' message="Keyspace ks doesn\'t exist"> > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12361) dtest failure in cql_tests.MiscellaneousCQLTester.prepared_statement_invalidation_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Knighton resolved CASSANDRA-12361. --- Resolution: Fixed I haven't seen this fail on any branch since the revert. > dtest failure in > cql_tests.MiscellaneousCQLTester.prepared_statement_invalidation_test > -- > > Key: CASSANDRA-12361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12361 > Project: Cassandra > Issue Type: Bug >Reporter: Sean McCarthy >Assignee: Joel Knighton > Labels: dtest > Attachments: node1.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_dtest/497/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/cql_tests.py", line 481, in > prepared_statement_invalidation_test > result = session.execute(wildcard_prepared.bind(None)) > File "cassandra/cluster.py", line 1961, in > cassandra.cluster.Session.execute (cassandra/cluster.c:34076) > return self.execute_async(query, parameters, trace, custom_payload, > timeout, execution_profile).result() > File "cassandra/cluster.py", line 3649, in > cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69755) > raise self._final_exception > "Cannot read past the end of the file > {code} > Related failures: > http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/250/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/ > http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/270/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/ > http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/380/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/ > http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/25/testReport/cql_tests/MiscellaneousCQLTester/prepared_statement_invalidation_test/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11031) MultiTenant : support “ALLOW FILTERING" for Partition Key
[ https://issues.apache.org/jira/browse/CASSANDRA-11031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412304#comment-15412304 ] Alex Petrov commented on CASSANDRA-11031: - [~jasonstack] I've made several changes in a separate commit, you can check them below. [~blerer] could you lend us another pair of eyes on the ticket? I've found a way to short-circuit several common cases for both partition and static restrictions, tests are looking good, but i'm biased now since I've touched the patch... |[trunk|https://github.com/ifesdjeen/cassandra/tree/11031-trunk]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11031-trunk-dtest/]|[testall|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11031-trunk-testall/]| > MultiTenant : support “ALLOW FILTERING" for Partition Key > - > > Key: CASSANDRA-11031 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11031 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Minor > Fix For: 3.x > > Attachments: CASSANDRA-11031-3.7.patch > > > Currently, Allow Filtering only works for secondary Index column or > clustering columns. And it's slow, because Cassandra will read all data from > SSTABLE from hard-disk to memory to filter. > But we can support allow filtering on Partition Key, as far as I know, > Partition Key is in memory, so we can easily filter them, and then read > required data from SSTable. > This will similar to "Select * from table" which scan through entire cluster. > CREATE TABLE multi_tenant_table ( > tenant_id text, > pk2 text, > c1 text, > c2 text, > v1 text, > v2 text, > PRIMARY KEY ((tenant_id,pk2),c1,c2) > ) ; > Select * from multi_tenant_table where tenant_id = "datastax" allow filtering; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12196) dtest failure in upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_2_1_x_To_indev_3_x.bootstrap_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson reassigned CASSANDRA-12196: --- Assignee: Philip Thompson (was: DS Test Eng) > dtest failure in > upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_2_1_x_To_indev_3_x.bootstrap_test > -- > > Key: CASSANDRA-12196 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12196 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: Philip Thompson > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log, > node4.log, node4_debug.log, node4_gc.log > > > example failure: > http://cassci.datastax.com/job/upgrade_tests-all/59/testReport/upgrade_tests.upgrade_through_versions_test/TestUpgrade_current_2_1_x_To_indev_3_x/bootstrap_test > Failed on CassCI build upgrade_tests-all #59 > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File > "/home/automaton/cassandra-dtest/upgrade_tests/upgrade_through_versions_test.py", > line 707, in bootstrap_test > self.upgrade_scenario(after_upgrade_call=(self._bootstrap_new_node,)) > File > "/home/automaton/cassandra-dtest/upgrade_tests/upgrade_through_versions_test.py", > line 383, in upgrade_scenario > call() > File > "/home/automaton/cassandra-dtest/upgrade_tests/upgrade_through_versions_test.py", > line 688, in _bootstrap_new_node > nnode.start(use_jna=True, wait_other_notice=True, > wait_for_binary_proto=True) > File "/home/automaton/ccm/ccmlib/node.py", line 634, in start > node.watch_log_for_alive(self, from_mark=mark) > File "/home/automaton/ccm/ccmlib/node.py", line 481, in watch_log_for_alive > self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout, > filename=filename) > File "/home/automaton/ccm/ccmlib/node.py", line 449, in watch_log_for > raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + " > [" + self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" + > reads[:50] + ".\nSee {} for remainder".format(filename)) > "13 Jul 2016 02:23:05 [node2] Missing: ['127.0.0.4.* now UP']:\nINFO > [HANDSHAKE-/127.0.0.4] 2016-07-13 02:21:00,2.\nSee system.log for > remainder > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12196) dtest failure in upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_2_1_x_To_indev_3_x.bootstrap_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412276#comment-15412276 ] Philip Thompson commented on CASSANDRA-12196: - I bumped up that timeout I mentioned, and am running here: http://cassci.datastax.com/view/trunk/job/trunk_large_dtest/21/ > dtest failure in > upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_2_1_x_To_indev_3_x.bootstrap_test > -- > > Key: CASSANDRA-12196 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12196 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: DS Test Eng > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log, > node4.log, node4_debug.log, node4_gc.log > > > example failure: > http://cassci.datastax.com/job/upgrade_tests-all/59/testReport/upgrade_tests.upgrade_through_versions_test/TestUpgrade_current_2_1_x_To_indev_3_x/bootstrap_test > Failed on CassCI build upgrade_tests-all #59 > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File > "/home/automaton/cassandra-dtest/upgrade_tests/upgrade_through_versions_test.py", > line 707, in bootstrap_test > self.upgrade_scenario(after_upgrade_call=(self._bootstrap_new_node,)) > File > "/home/automaton/cassandra-dtest/upgrade_tests/upgrade_through_versions_test.py", > line 383, in upgrade_scenario > call() > File > "/home/automaton/cassandra-dtest/upgrade_tests/upgrade_through_versions_test.py", > line 688, in _bootstrap_new_node > nnode.start(use_jna=True, wait_other_notice=True, > wait_for_binary_proto=True) > File "/home/automaton/ccm/ccmlib/node.py", line 634, in start > node.watch_log_for_alive(self, from_mark=mark) > File "/home/automaton/ccm/ccmlib/node.py", line 481, in watch_log_for_alive > self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout, > filename=filename) > File "/home/automaton/ccm/ccmlib/node.py", line 449, in watch_log_for > raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + " > [" + self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" + > reads[:50] + ".\nSee {} for remainder".format(filename)) > "13 Jul 2016 02:23:05 [node2] Missing: ['127.0.0.4.* now UP']:\nINFO > [HANDSHAKE-/127.0.0.4] 2016-07-13 02:21:00,2.\nSee system.log for > remainder > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12092) dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters
[ https://issues.apache.org/jira/browse/CASSANDRA-12092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412212#comment-15412212 ] Sean McCarthy commented on CASSANDRA-12092: --- Running a multiplex (1000 iterations) to test if {quote} it is really always the first key of QUORUM/ONE/- {quote} http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/222/ Also running a 2.2 and trunk multiplex tests. Trunk: http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/223/ 2.2 http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/224/ > dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters > > > Key: CASSANDRA-12092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12092 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: Sean McCarthy > Labels: dtest > Attachments: node1.log, node2.log, node3.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_dtest/484/testReport/consistency_test/TestAccuracy/test_simple_strategy_counters > Failed on CassCI build cassandra-2.1_dtest #484 > {code} > Standard Error > Traceback (most recent call last): > File "/home/automaton/cassandra-dtest/consistency_test.py", line 514, in run > valid_fcn(v) > File "/home/automaton/cassandra-dtest/consistency_test.py", line 497, in > validate_counters > check_all_sessions(s, n, c) > File "/home/automaton/cassandra-dtest/consistency_test.py", line 490, in > check_all_sessions > "value of %s at key %d, instead got these values: %s" % (write_nodes, > val, n, results) > AssertionError: Failed to read value from sufficient number of nodes, > required 2 nodes to have a counter value of 1 at key 200, instead got these > values: [0, 0, 1] > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12092) dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters
[ https://issues.apache.org/jira/browse/CASSANDRA-12092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12092: Assignee: Sean McCarthy (was: DS Test Eng) > dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters > > > Key: CASSANDRA-12092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12092 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: Sean McCarthy > Labels: dtest > Attachments: node1.log, node2.log, node3.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_dtest/484/testReport/consistency_test/TestAccuracy/test_simple_strategy_counters > Failed on CassCI build cassandra-2.1_dtest #484 > {code} > Standard Error > Traceback (most recent call last): > File "/home/automaton/cassandra-dtest/consistency_test.py", line 514, in run > valid_fcn(v) > File "/home/automaton/cassandra-dtest/consistency_test.py", line 497, in > validate_counters > check_all_sessions(s, n, c) > File "/home/automaton/cassandra-dtest/consistency_test.py", line 490, in > check_all_sessions > "value of %s at key %d, instead got these values: %s" % (write_nodes, > val, n, results) > AssertionError: Failed to read value from sufficient number of nodes, > required 2 nodes to have a counter value of 1 at key 200, instead got these > values: [0, 0, 1] > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12225) dtest failure in materialized_views_test.TestMaterializedViews.clustering_column_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson reassigned CASSANDRA-12225: --- Assignee: Philip Thompson (was: DS Test Eng) > dtest failure in > materialized_views_test.TestMaterializedViews.clustering_column_test > - > > Key: CASSANDRA-12225 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12225 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: Philip Thompson > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log > > > example failure: > http://cassci.datastax.com/job/trunk_offheap_dtest/336/testReport/materialized_views_test/TestMaterializedViews/clustering_column_test > Failed on CassCI build trunk_offheap_dtest #336 > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/materialized_views_test.py", line > 321, in clustering_column_test > self.assertEqual(len(result), 2, "Expecting {} users, got {}".format(2, > len(result))) > File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual > assertion_func(first, second, msg=msg) > File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual > raise self.failureException(msg) > "Expecting 2 users, got 1 > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12285) dtest failure in user_functions_test.TestUserFunctions.test_migration
[ https://issues.apache.org/jira/browse/CASSANDRA-12285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12285: Resolution: Fixed Status: Resolved (was: Patch Available) > dtest failure in user_functions_test.TestUserFunctions.test_migration > - > > Key: CASSANDRA-12285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12285 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: Philip Thompson > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log > > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_dtest/17/testReport/user_functions_test/TestUserFunctions/test_migration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12148) Improve determinism of CDC data availability
[ https://issues.apache.org/jira/browse/CASSANDRA-12148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-12148: Status: Open (was: Ready to Commit) Not RTC until I finish the dtest proving replay links and marks .idx file correctly. > Improve determinism of CDC data availability > > > Key: CASSANDRA-12148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12148 > Project: Cassandra > Issue Type: Improvement >Reporter: Joshua McKenzie >Assignee: Joshua McKenzie > > The latency with which CDC data becomes available has a known limitation due > to our reliance on CommitLogSegments being discarded to have the data > available in cdc_raw: if a slowly written table co-habitates a > CommitLogSegment with CDC data, the CommitLogSegment won't be flushed until > we hit either memory pressure on memtables or CommitLog limit pressure. > Ultimately, this leaves a non-deterministic element to when data becomes > available for CDC consumption unless a consumer parses live CommitLogSegments. > To work around this limitation and make semi-realtime CDC consumption more > friendly to end-users, I propose we extend CDC as follows: > h6. High level: > * Consumers parse hard links of active CommitLogSegments in cdc_raw instead > of waiting for flush/discard and file move > * C* stores an offset of the highest seen CDC mutation in a separate idx file > per commit log segment in cdc_raw. Clients tail this index file, delta their > local last parsed offset on change, and parse the corresponding commit log > segment using their last parsed offset as min > * C* flags that index file with an offset and DONE when the file is flushed > so clients know when they can clean up > h6. Details: > * On creation of a CommitLogSegment, also hard-link the file in cdc_raw > * On first write of a CDC-enabled mutation to a segment, we: > ** Flag it as {{CDCState.CONTAINS}} > ** Set a long tracking the {{CommitLogPosition}} of the 1st CDC-enabled > mutation in the log > ** Set a long in the CommitLogSegment tracking the offset of the end of the > last written CDC mutation in the segment if higher than the previously known > highest CDC offset > * On subsequent writes to the segment, we update the offset of the highest > known CDC data > * On CommitLogSegment fsync, we write a file in cdc_raw as > _cdc.idx containing the min offset and end offset fsynced to > disk per file > * On segment discard, if CDCState == {{CDCState.PERMITTED}}, delete both the > segment in commitlog and in cdc_raw > * On segment discard, if CDCState == {{CDCState.CONTAINS}}, delete the > segment in commitlog and update the _cdc.idx file w/end offset > and a DONE marker > * On segment replay, store the highest end offset of seen CDC-enabled > mutations from a segment and write that to _cdc.idx on > completion of segment replay. This should bridge the potential correctness > gap of a node writing to a segment and then dying before it can write the > _cdc.idx file. > This should allow clients to skip the beginning of a file to the 1st CDC > mutation, track an offset of how far they've parsed, delta against the > _cdc.idx file end offset, and use that as a determinant on when to parse new > CDC data. Any existing clients written to the initial implementation of CDC > need only add the _cdc.idx logic and checking for DONE marker > to their code, so the burden on users to update to support this should be > quite small for the benefit of having data available as soon as it's fsynced > instead of at a non-deterministic time when potentially unrelated tables are > flushed. > Finally, we should look into extending the interface on CommitLogReader to be > more friendly for realtime parsing, perhaps supporting taking a > CommitLogDescriptor and RandomAccessReader and resuming readSection calls, > assuming the reader is at the start of a SyncSegment. Would probably also > need to rewind to the start of the segment before returning so subsequent > calls would respect this contract. This would skip needing to deserialize the > descriptor and all completed SyncSegments to get to the root of the desired > segment for parsing. > One alternative we discussed offline - instead of just storing the highest > seen CDC offset, we could instead store an offset per CDC mutation > (potentially delta encoded) in the idx file to allow clients to seek and only > parse the mutations with CDC enabled. My hunch is that the performance delta > from doing so wouldn't justify the complexity given the SyncSegment > deserialization and seeking restrictions in the compressed and encrypted > cases as mentioned above. > The only complication I can think of with the above design is uncompressed > mmapped CommitLogSegments on Windows being
[jira] [Commented] (CASSANDRA-10848) Upgrade paging dtests involving deletion flap on CassCI
[ https://issues.apache.org/jira/browse/CASSANDRA-10848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412149#comment-15412149 ] Russ Hatch commented on CASSANDRA-10848: Ah ok, I misunderstood. Got a PR open for that change too, here: https://github.com/riptano/cassandra-dtest/pull/1190. > Upgrade paging dtests involving deletion flap on CassCI > --- > > Key: CASSANDRA-10848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10848 > Project: Cassandra > Issue Type: Bug >Reporter: Jim Witschey >Assignee: Russ Hatch > Labels: dtest > Fix For: 3.0.x, 3.x > > > A number of dtests in the {{upgrade_tests.paging_tests}} that involve > deletion flap with the following error: > {code} > Requested pages were not delivered before timeout. > {code} > This may just be an effect of CASSANDRA-10730, but it's worth having a look > at separately. Here are some examples of tests flapping in this way: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12335) Super columns are broken after upgrading to 3.0 on thrift
[ https://issues.apache.org/jira/browse/CASSANDRA-12335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-12335: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Super columns are broken after upgrading to 3.0 on thrift > - > > Key: CASSANDRA-12335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12335 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jeremiah Jordan >Assignee: Sylvain Lebresne > Fix For: 3.0.9, 3.9 > > Attachments: 0001-Fix-encoding-of-cell-names-for-super-columns.txt, > 0001-Force-super-column-families-to-be-compound.txt > > > Super Columns are broken after upgrading to cassandra-3.0 HEAD. The below > script shows this. > 2.1 cli output for get: > {code} > [default@test] get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8; > => (name=name, value=Bob, timestamp=1469724504357000) > {code} > cqlsh: > {code} > [default@test] > key | blobAsText(column1) > --+- > 0x53696d6f6e |attr > 0x426f62 |attr > {code} > 3.0 cli: > {code} > [default@unknown] use test; > unconfigured table schema_columnfamilies > [default@test] get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8; > null > [default@test] > {code} > cqlsh: > {code} > key | system.blobastext(column1) > --+-- > 0x53696d6f6e | \x00\x04attr\x00\x00\x04name\x00 > 0x426f62 | \x00\x04attr\x00\x00\x04name\x00 > {code} > Run this from a directory with cassandra-3.0 checked out and compiled > {code} > ccm create -n 2 -v 2.1.14 testsuper > echo "### Starting 2.1 ###" > ccm start > MYFILE=`mktemp` > echo "create keyspace test with placement_strategy = > 'org.apache.cassandra.locator.SimpleStrategy' and strategy_options = > {replication_factor:2}; > use test; > create column family Sites with column_type = 'Super' and comparator = > 'BytesType' and subcomparator='UTF8Type'; > set Sites[utf8('Simon')][utf8('attr')]['name'] = utf8('Simon'); > set Sites[utf8('Bob')][utf8('attr')]['name'] = utf8('Bob'); > get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;" > $MYFILE > ~/.ccm/repository/2.1.14/bin/cassandra-cli < $MYFILE > rm $MYFILE > ~/.ccm/repository/2.1.14/bin/nodetool -p 7100 flush > ~/.ccm/repository/2.1.14/bin/nodetool -p 7200 flush > ccm stop > # run from cassandra-3.0 checked out and compiled > ccm setdir > echo "### Starting Current Directory > ###" > ccm start > ./bin/nodetool -p 7100 upgradesstables > ./bin/nodetool -p 7200 upgradesstables > ./bin/nodetool -p 7100 enablethrift > ./bin/nodetool -p 7200 enablethrift > MYFILE=`mktemp` > echo "use test; > get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;" > $MYFILE > ~/.ccm/repository/2.1.14/bin/cassandra-cli < $MYFILE > rm $MYFILE > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12335) Super columns are broken after upgrading to 3.0 on thrift
[ https://issues.apache.org/jira/browse/CASSANDRA-12335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412140#comment-15412140 ] Aleksey Yeschenko edited comment on CASSANDRA-12335 at 8/8/16 5:42 PM: --- Committed follow-up as [ae816cb84f24de410a5e4b0b2e73507eca37f655|https://github.com/apache/cassandra/commit/ae816cb84f24de410a5e4b0b2e73507eca37f655] to 3.9 and trunk, thanks. Edit: and back-ported to 3.0. was (Author: iamaleksey): Committed follow-up as [ae816cb84f24de410a5e4b0b2e73507eca37f655|https://github.com/apache/cassandra/commit/ae816cb84f24de410a5e4b0b2e73507eca37f655] to 3.9 and trunk, thanks. > Super columns are broken after upgrading to 3.0 on thrift > - > > Key: CASSANDRA-12335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12335 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jeremiah Jordan >Assignee: Sylvain Lebresne > Fix For: 3.0.9, 3.9 > > Attachments: 0001-Fix-encoding-of-cell-names-for-super-columns.txt, > 0001-Force-super-column-families-to-be-compound.txt > > > Super Columns are broken after upgrading to cassandra-3.0 HEAD. The below > script shows this. > 2.1 cli output for get: > {code} > [default@test] get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8; > => (name=name, value=Bob, timestamp=1469724504357000) > {code} > cqlsh: > {code} > [default@test] > key | blobAsText(column1) > --+- > 0x53696d6f6e |attr > 0x426f62 |attr > {code} > 3.0 cli: > {code} > [default@unknown] use test; > unconfigured table schema_columnfamilies > [default@test] get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8; > null > [default@test] > {code} > cqlsh: > {code} > key | system.blobastext(column1) > --+-- > 0x53696d6f6e | \x00\x04attr\x00\x00\x04name\x00 > 0x426f62 | \x00\x04attr\x00\x00\x04name\x00 > {code} > Run this from a directory with cassandra-3.0 checked out and compiled > {code} > ccm create -n 2 -v 2.1.14 testsuper > echo "### Starting 2.1 ###" > ccm start > MYFILE=`mktemp` > echo "create keyspace test with placement_strategy = > 'org.apache.cassandra.locator.SimpleStrategy' and strategy_options = > {replication_factor:2}; > use test; > create column family Sites with column_type = 'Super' and comparator = > 'BytesType' and subcomparator='UTF8Type'; > set Sites[utf8('Simon')][utf8('attr')]['name'] = utf8('Simon'); > set Sites[utf8('Bob')][utf8('attr')]['name'] = utf8('Bob'); > get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;" > $MYFILE > ~/.ccm/repository/2.1.14/bin/cassandra-cli < $MYFILE > rm $MYFILE > ~/.ccm/repository/2.1.14/bin/nodetool -p 7100 flush > ~/.ccm/repository/2.1.14/bin/nodetool -p 7200 flush > ccm stop > # run from cassandra-3.0 checked out and compiled > ccm setdir > echo "### Starting Current Directory > ###" > ccm start > ./bin/nodetool -p 7100 upgradesstables > ./bin/nodetool -p 7200 upgradesstables > ./bin/nodetool -p 7100 enablethrift > ./bin/nodetool -p 7200 enablethrift > MYFILE=`mktemp` > echo "use test; > get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;" > $MYFILE > ~/.ccm/repository/2.1.14/bin/cassandra-cli < $MYFILE > rm $MYFILE > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[3/6] cassandra git commit: Fix encoding of cell names for super columns (CASSANDRA-12235 follow-up)
Fix encoding of cell names for super columns (CASSANDRA-12235 follow-up) patch by Sylvain Lebresne; reviewed by Aleksey Yeschenko for CASSANDRA-12335 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/676b6a89 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/676b6a89 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/676b6a89 Branch: refs/heads/trunk Commit: 676b6a891d110cbbc5278a0fe06c4d937648ddea Parents: 47e63fe Author: Sylvain Lebresne Authored: Fri Aug 5 09:36:09 2016 +0200 Committer: Aleksey Yeschenko Committed: Mon Aug 8 18:40:31 2016 +0100 -- .../org/apache/cassandra/db/LegacyLayout.java | 23 1 file changed, 19 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/676b6a89/src/java/org/apache/cassandra/db/LegacyLayout.java -- diff --git a/src/java/org/apache/cassandra/db/LegacyLayout.java b/src/java/org/apache/cassandra/db/LegacyLayout.java index 3feb1f4..1dd4c5d 100644 --- a/src/java/org/apache/cassandra/db/LegacyLayout.java +++ b/src/java/org/apache/cassandra/db/LegacyLayout.java @@ -264,6 +264,8 @@ public abstract class LegacyLayout // We use comparator.size() rather than clustering.size() because of static clusterings int clusteringSize = metadata.comparator.size(); int size = clusteringSize + (metadata.isDense() ? 0 : 1) + (collectionElement == null ? 0 : 1); +if (metadata.isSuper()) +size = clusteringSize + 1; ByteBuffer[] values = new ByteBuffer[size]; for (int i = 0; i < clusteringSize; i++) { @@ -282,10 +284,23 @@ public abstract class LegacyLayout values[i] = v; } -if (!metadata.isDense()) -values[clusteringSize] = columnName; -if (collectionElement != null) -values[clusteringSize + 1] = collectionElement; +if (metadata.isSuper()) +{ +// We need to set the "column" (in thrift terms) name, i.e. the value corresponding to the subcomparator. +// What it is depends if this a cell for a declared "static" column or a "dynamic" column part of the +// super-column internal map. +assert columnName != null; // This should never be null for supercolumns, see decodeForSuperColumn() above +values[clusteringSize] = columnName.equals(CompactTables.SUPER_COLUMN_MAP_COLUMN) + ? collectionElement + : columnName; +} +else +{ +if (!metadata.isDense()) +values[clusteringSize] = columnName; +if (collectionElement != null) +values[clusteringSize + 1] = collectionElement; +} return CompositeType.build(isStatic, values); }
[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.9
Merge branch 'cassandra-3.0' into cassandra-3.9 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/02ebf875 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/02ebf875 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/02ebf875 Branch: refs/heads/trunk Commit: 02ebf875b1a07c79e18bc1f21878c51ed67cb9c4 Parents: ae816cb 676b6a8 Author: Aleksey Yeschenko Authored: Mon Aug 8 18:41:23 2016 +0100 Committer: Aleksey Yeschenko Committed: Mon Aug 8 18:41:23 2016 +0100 -- --
[2/6] cassandra git commit: Fix encoding of cell names for super columns (CASSANDRA-12235 follow-up)
Fix encoding of cell names for super columns (CASSANDRA-12235 follow-up) patch by Sylvain Lebresne; reviewed by Aleksey Yeschenko for CASSANDRA-12335 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/676b6a89 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/676b6a89 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/676b6a89 Branch: refs/heads/cassandra-3.9 Commit: 676b6a891d110cbbc5278a0fe06c4d937648ddea Parents: 47e63fe Author: Sylvain Lebresne Authored: Fri Aug 5 09:36:09 2016 +0200 Committer: Aleksey Yeschenko Committed: Mon Aug 8 18:40:31 2016 +0100 -- .../org/apache/cassandra/db/LegacyLayout.java | 23 1 file changed, 19 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/676b6a89/src/java/org/apache/cassandra/db/LegacyLayout.java -- diff --git a/src/java/org/apache/cassandra/db/LegacyLayout.java b/src/java/org/apache/cassandra/db/LegacyLayout.java index 3feb1f4..1dd4c5d 100644 --- a/src/java/org/apache/cassandra/db/LegacyLayout.java +++ b/src/java/org/apache/cassandra/db/LegacyLayout.java @@ -264,6 +264,8 @@ public abstract class LegacyLayout // We use comparator.size() rather than clustering.size() because of static clusterings int clusteringSize = metadata.comparator.size(); int size = clusteringSize + (metadata.isDense() ? 0 : 1) + (collectionElement == null ? 0 : 1); +if (metadata.isSuper()) +size = clusteringSize + 1; ByteBuffer[] values = new ByteBuffer[size]; for (int i = 0; i < clusteringSize; i++) { @@ -282,10 +284,23 @@ public abstract class LegacyLayout values[i] = v; } -if (!metadata.isDense()) -values[clusteringSize] = columnName; -if (collectionElement != null) -values[clusteringSize + 1] = collectionElement; +if (metadata.isSuper()) +{ +// We need to set the "column" (in thrift terms) name, i.e. the value corresponding to the subcomparator. +// What it is depends if this a cell for a declared "static" column or a "dynamic" column part of the +// super-column internal map. +assert columnName != null; // This should never be null for supercolumns, see decodeForSuperColumn() above +values[clusteringSize] = columnName.equals(CompactTables.SUPER_COLUMN_MAP_COLUMN) + ? collectionElement + : columnName; +} +else +{ +if (!metadata.isDense()) +values[clusteringSize] = columnName; +if (collectionElement != null) +values[clusteringSize + 1] = collectionElement; +} return CompositeType.build(isStatic, values); }
[jira] [Commented] (CASSANDRA-12335) Super columns are broken after upgrading to 3.0 on thrift
[ https://issues.apache.org/jira/browse/CASSANDRA-12335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412140#comment-15412140 ] Aleksey Yeschenko commented on CASSANDRA-12335: --- Committed follow-up as [ae816cb84f24de410a5e4b0b2e73507eca37f655|https://github.com/apache/cassandra/commit/ae816cb84f24de410a5e4b0b2e73507eca37f655] to 3.9 and trunk, thanks. > Super columns are broken after upgrading to 3.0 on thrift > - > > Key: CASSANDRA-12335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12335 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jeremiah Jordan >Assignee: Sylvain Lebresne > Fix For: 3.0.9, 3.9 > > Attachments: 0001-Fix-encoding-of-cell-names-for-super-columns.txt, > 0001-Force-super-column-families-to-be-compound.txt > > > Super Columns are broken after upgrading to cassandra-3.0 HEAD. The below > script shows this. > 2.1 cli output for get: > {code} > [default@test] get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8; > => (name=name, value=Bob, timestamp=1469724504357000) > {code} > cqlsh: > {code} > [default@test] > key | blobAsText(column1) > --+- > 0x53696d6f6e |attr > 0x426f62 |attr > {code} > 3.0 cli: > {code} > [default@unknown] use test; > unconfigured table schema_columnfamilies > [default@test] get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8; > null > [default@test] > {code} > cqlsh: > {code} > key | system.blobastext(column1) > --+-- > 0x53696d6f6e | \x00\x04attr\x00\x00\x04name\x00 > 0x426f62 | \x00\x04attr\x00\x00\x04name\x00 > {code} > Run this from a directory with cassandra-3.0 checked out and compiled > {code} > ccm create -n 2 -v 2.1.14 testsuper > echo "### Starting 2.1 ###" > ccm start > MYFILE=`mktemp` > echo "create keyspace test with placement_strategy = > 'org.apache.cassandra.locator.SimpleStrategy' and strategy_options = > {replication_factor:2}; > use test; > create column family Sites with column_type = 'Super' and comparator = > 'BytesType' and subcomparator='UTF8Type'; > set Sites[utf8('Simon')][utf8('attr')]['name'] = utf8('Simon'); > set Sites[utf8('Bob')][utf8('attr')]['name'] = utf8('Bob'); > get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;" > $MYFILE > ~/.ccm/repository/2.1.14/bin/cassandra-cli < $MYFILE > rm $MYFILE > ~/.ccm/repository/2.1.14/bin/nodetool -p 7100 flush > ~/.ccm/repository/2.1.14/bin/nodetool -p 7200 flush > ccm stop > # run from cassandra-3.0 checked out and compiled > ccm setdir > echo "### Starting Current Directory > ###" > ccm start > ./bin/nodetool -p 7100 upgradesstables > ./bin/nodetool -p 7200 upgradesstables > ./bin/nodetool -p 7100 enablethrift > ./bin/nodetool -p 7200 enablethrift > MYFILE=`mktemp` > echo "use test; > get Sites[utf8('Bob')][utf8('attr')]['name'] as utf8;" > $MYFILE > ~/.ccm/repository/2.1.14/bin/cassandra-cli < $MYFILE > rm $MYFILE > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[1/6] cassandra git commit: Fix encoding of cell names for super columns (CASSANDRA-12235 follow-up)
Repository: cassandra Updated Branches: refs/heads/cassandra-3.0 47e63feb1 -> 676b6a891 refs/heads/cassandra-3.9 ae816cb84 -> 02ebf875b refs/heads/trunk e9132b29a -> 0565690de Fix encoding of cell names for super columns (CASSANDRA-12235 follow-up) patch by Sylvain Lebresne; reviewed by Aleksey Yeschenko for CASSANDRA-12335 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/676b6a89 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/676b6a89 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/676b6a89 Branch: refs/heads/cassandra-3.0 Commit: 676b6a891d110cbbc5278a0fe06c4d937648ddea Parents: 47e63fe Author: Sylvain Lebresne Authored: Fri Aug 5 09:36:09 2016 +0200 Committer: Aleksey Yeschenko Committed: Mon Aug 8 18:40:31 2016 +0100 -- .../org/apache/cassandra/db/LegacyLayout.java | 23 1 file changed, 19 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/676b6a89/src/java/org/apache/cassandra/db/LegacyLayout.java -- diff --git a/src/java/org/apache/cassandra/db/LegacyLayout.java b/src/java/org/apache/cassandra/db/LegacyLayout.java index 3feb1f4..1dd4c5d 100644 --- a/src/java/org/apache/cassandra/db/LegacyLayout.java +++ b/src/java/org/apache/cassandra/db/LegacyLayout.java @@ -264,6 +264,8 @@ public abstract class LegacyLayout // We use comparator.size() rather than clustering.size() because of static clusterings int clusteringSize = metadata.comparator.size(); int size = clusteringSize + (metadata.isDense() ? 0 : 1) + (collectionElement == null ? 0 : 1); +if (metadata.isSuper()) +size = clusteringSize + 1; ByteBuffer[] values = new ByteBuffer[size]; for (int i = 0; i < clusteringSize; i++) { @@ -282,10 +284,23 @@ public abstract class LegacyLayout values[i] = v; } -if (!metadata.isDense()) -values[clusteringSize] = columnName; -if (collectionElement != null) -values[clusteringSize + 1] = collectionElement; +if (metadata.isSuper()) +{ +// We need to set the "column" (in thrift terms) name, i.e. the value corresponding to the subcomparator. +// What it is depends if this a cell for a declared "static" column or a "dynamic" column part of the +// super-column internal map. +assert columnName != null; // This should never be null for supercolumns, see decodeForSuperColumn() above +values[clusteringSize] = columnName.equals(CompactTables.SUPER_COLUMN_MAP_COLUMN) + ? collectionElement + : columnName; +} +else +{ +if (!metadata.isDense()) +values[clusteringSize] = columnName; +if (collectionElement != null) +values[clusteringSize + 1] = collectionElement; +} return CompositeType.build(isStatic, values); }
[6/6] cassandra git commit: Merge branch 'cassandra-3.9' into trunk
Merge branch 'cassandra-3.9' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0565690d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0565690d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0565690d Branch: refs/heads/trunk Commit: 0565690ded9d1922cf318d170d83cbc94888d2be Parents: e9132b2 02ebf87 Author: Aleksey Yeschenko Authored: Mon Aug 8 18:41:32 2016 +0100 Committer: Aleksey Yeschenko Committed: Mon Aug 8 18:41:32 2016 +0100 -- --
[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.9
Merge branch 'cassandra-3.0' into cassandra-3.9 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/02ebf875 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/02ebf875 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/02ebf875 Branch: refs/heads/cassandra-3.9 Commit: 02ebf875b1a07c79e18bc1f21878c51ed67cb9c4 Parents: ae816cb 676b6a8 Author: Aleksey Yeschenko Authored: Mon Aug 8 18:41:23 2016 +0100 Committer: Aleksey Yeschenko Committed: Mon Aug 8 18:41:23 2016 +0100 -- --
[3/3] cassandra git commit: Merge branch 'cassandra-3.9' into trunk
Merge branch 'cassandra-3.9' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e9132b29 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e9132b29 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e9132b29 Branch: refs/heads/trunk Commit: e9132b29aa697c84f6030432a3530bed405246e0 Parents: 938faa2 ae816cb Author: Aleksey Yeschenko Authored: Mon Aug 8 18:38:27 2016 +0100 Committer: Aleksey Yeschenko Committed: Mon Aug 8 18:38:27 2016 +0100 -- .../org/apache/cassandra/db/LegacyLayout.java | 23 1 file changed, 19 insertions(+), 4 deletions(-) --
[2/3] cassandra git commit: Fix encoding of cell names for super columns (CASSANDRA-12235 follow-up)
Fix encoding of cell names for super columns (CASSANDRA-12235 follow-up) patch by Sylvain Lebresne; reviewed by Aleksey Yeschenko for CASSANDRA-12335 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ae816cb8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ae816cb8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ae816cb8 Branch: refs/heads/trunk Commit: ae816cb84f24de410a5e4b0b2e73507eca37f655 Parents: 55aea2d Author: Sylvain Lebresne Authored: Fri Aug 5 09:36:09 2016 +0200 Committer: Aleksey Yeschenko Committed: Mon Aug 8 18:36:59 2016 +0100 -- .../org/apache/cassandra/db/LegacyLayout.java | 23 1 file changed, 19 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae816cb8/src/java/org/apache/cassandra/db/LegacyLayout.java -- diff --git a/src/java/org/apache/cassandra/db/LegacyLayout.java b/src/java/org/apache/cassandra/db/LegacyLayout.java index b5190ad..9e7e9b6 100644 --- a/src/java/org/apache/cassandra/db/LegacyLayout.java +++ b/src/java/org/apache/cassandra/db/LegacyLayout.java @@ -264,6 +264,8 @@ public abstract class LegacyLayout // We use comparator.size() rather than clustering.size() because of static clusterings int clusteringSize = metadata.comparator.size(); int size = clusteringSize + (metadata.isDense() ? 0 : 1) + (collectionElement == null ? 0 : 1); +if (metadata.isSuper()) +size = clusteringSize + 1; ByteBuffer[] values = new ByteBuffer[size]; for (int i = 0; i < clusteringSize; i++) { @@ -282,10 +284,23 @@ public abstract class LegacyLayout values[i] = v; } -if (!metadata.isDense()) -values[clusteringSize] = columnName; -if (collectionElement != null) -values[clusteringSize + 1] = collectionElement; +if (metadata.isSuper()) +{ +// We need to set the "column" (in thrift terms) name, i.e. the value corresponding to the subcomparator. +// What it is depends if this a cell for a declared "static" column or a "dynamic" column part of the +// super-column internal map. +assert columnName != null; // This should never be null for supercolumns, see decodeForSuperColumn() above +values[clusteringSize] = columnName.equals(CompactTables.SUPER_COLUMN_MAP_COLUMN) + ? collectionElement + : columnName; +} +else +{ +if (!metadata.isDense()) +values[clusteringSize] = columnName; +if (collectionElement != null) +values[clusteringSize + 1] = collectionElement; +} return CompositeType.build(isStatic, values); }
[1/3] cassandra git commit: Fix encoding of cell names for super columns (CASSANDRA-12235 follow-up)
Repository: cassandra Updated Branches: refs/heads/cassandra-3.9 55aea2db8 -> ae816cb84 refs/heads/trunk 938faa216 -> e9132b29a Fix encoding of cell names for super columns (CASSANDRA-12235 follow-up) patch by Sylvain Lebresne; reviewed by Aleksey Yeschenko for CASSANDRA-12335 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ae816cb8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ae816cb8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ae816cb8 Branch: refs/heads/cassandra-3.9 Commit: ae816cb84f24de410a5e4b0b2e73507eca37f655 Parents: 55aea2d Author: Sylvain Lebresne Authored: Fri Aug 5 09:36:09 2016 +0200 Committer: Aleksey Yeschenko Committed: Mon Aug 8 18:36:59 2016 +0100 -- .../org/apache/cassandra/db/LegacyLayout.java | 23 1 file changed, 19 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae816cb8/src/java/org/apache/cassandra/db/LegacyLayout.java -- diff --git a/src/java/org/apache/cassandra/db/LegacyLayout.java b/src/java/org/apache/cassandra/db/LegacyLayout.java index b5190ad..9e7e9b6 100644 --- a/src/java/org/apache/cassandra/db/LegacyLayout.java +++ b/src/java/org/apache/cassandra/db/LegacyLayout.java @@ -264,6 +264,8 @@ public abstract class LegacyLayout // We use comparator.size() rather than clustering.size() because of static clusterings int clusteringSize = metadata.comparator.size(); int size = clusteringSize + (metadata.isDense() ? 0 : 1) + (collectionElement == null ? 0 : 1); +if (metadata.isSuper()) +size = clusteringSize + 1; ByteBuffer[] values = new ByteBuffer[size]; for (int i = 0; i < clusteringSize; i++) { @@ -282,10 +284,23 @@ public abstract class LegacyLayout values[i] = v; } -if (!metadata.isDense()) -values[clusteringSize] = columnName; -if (collectionElement != null) -values[clusteringSize + 1] = collectionElement; +if (metadata.isSuper()) +{ +// We need to set the "column" (in thrift terms) name, i.e. the value corresponding to the subcomparator. +// What it is depends if this a cell for a declared "static" column or a "dynamic" column part of the +// super-column internal map. +assert columnName != null; // This should never be null for supercolumns, see decodeForSuperColumn() above +values[clusteringSize] = columnName.equals(CompactTables.SUPER_COLUMN_MAP_COLUMN) + ? collectionElement + : columnName; +} +else +{ +if (!metadata.isDense()) +values[clusteringSize] = columnName; +if (collectionElement != null) +values[clusteringSize + 1] = collectionElement; +} return CompositeType.build(isStatic, values); }
[jira] [Commented] (CASSANDRA-12411) Do not store passwords in .cassandra/cqlsh_history
[ https://issues.apache.org/jira/browse/CASSANDRA-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412099#comment-15412099 ] Robert Stupp commented on CASSANDRA-12411: -- Question here is: how shall cqlsh detect that e.g. {{we23dwenvhe}} is a password? What I mean is, that {{CRETE USER foo WITH PASSWORD 'bar';}} contains a valid password - but there's a syntax error in it - so cqlsh would not know that {{bar}} is a password. Passwords are just a special kind of sensitive information - and sensitive information could also be in DML statements. IMO a better and more general improvement would be a cqlsh command to disable/enable recording of commands in the history - e.g. {{HISTORY OFF}}/{{HISTORY ON}}. > Do not store passwords in .cassandra/cqlsh_history > -- > > Key: CASSANDRA-12411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12411 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: jonathan lacefield > > This is a request to ensure that passwords are not stored in the > cqlsh_history file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12412) dtest failure in upgrade_tests.paging_test.TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x.test_paging_using_secondary_indexes
Craig Kodman created CASSANDRA-12412: Summary: dtest failure in upgrade_tests.paging_test.TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x.test_paging_using_secondary_indexes Key: CASSANDRA-12412 URL: https://issues.apache.org/jira/browse/CASSANDRA-12412 Project: Cassandra Issue Type: Test Reporter: Craig Kodman Assignee: DS Test Eng example failure: http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/22/testReport/upgrade_tests.paging_test/TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x/test_paging_using_secondary_indexes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12412) dtest failure in upgrade_tests.paging_test.TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x.test_paging_using_secondary_indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-12412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson resolved CASSANDRA-12412. - Resolution: Duplicate > dtest failure in > upgrade_tests.paging_test.TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x.test_paging_using_secondary_indexes > --- > > Key: CASSANDRA-12412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12412 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/22/testReport/upgrade_tests.paging_test/TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x/test_paging_using_secondary_indexes > {code} > ERROR [MessagingService-Incoming-/127.0.0.1] 2016-08-06 02:34:06,595 > CassandraDaemon.java:201 - Exception in thread > Thread[MessagingService-Incoming-/127.0.0.1,5,main] > java.lang.AssertionError: null > at > org.apache.cassandra.db.ReadCommand$LegacyPagedRangeCommandSerializer.deserialize(ReadCommand.java:1042) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.db.ReadCommand$LegacyPagedRangeCommandSerializer.deserialize(ReadCommand.java:964) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at org.apache.cassandra.net.MessageIn.read(MessageIn.java:98) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:201) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:178) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:92) > ~[apache-cassandra-3.0.8.jar:3.0.8] > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12412) dtest failure in upgrade_tests.paging_test.TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x.test_paging_using_secondary_indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-12412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12412: Description: example failure: http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/22/testReport/upgrade_tests.paging_test/TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x/test_paging_using_secondary_indexes {code} ERROR [MessagingService-Incoming-/127.0.0.1] 2016-08-06 02:34:06,595 CassandraDaemon.java:201 - Exception in thread Thread[MessagingService-Incoming-/127.0.0.1,5,main] java.lang.AssertionError: null at org.apache.cassandra.db.ReadCommand$LegacyPagedRangeCommandSerializer.deserialize(ReadCommand.java:1042) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.db.ReadCommand$LegacyPagedRangeCommandSerializer.deserialize(ReadCommand.java:964) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.net.MessageIn.read(MessageIn.java:98) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:201) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:178) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:92) ~[apache-cassandra-3.0.8.jar:3.0.8] {code} was: example failure: http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/22/testReport/upgrade_tests.paging_test/TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x/test_paging_using_secondary_indexes > dtest failure in > upgrade_tests.paging_test.TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x.test_paging_using_secondary_indexes > --- > > Key: CASSANDRA-12412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12412 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/22/testReport/upgrade_tests.paging_test/TestPagingDataNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x/test_paging_using_secondary_indexes > {code} > ERROR [MessagingService-Incoming-/127.0.0.1] 2016-08-06 02:34:06,595 > CassandraDaemon.java:201 - Exception in thread > Thread[MessagingService-Incoming-/127.0.0.1,5,main] > java.lang.AssertionError: null > at > org.apache.cassandra.db.ReadCommand$LegacyPagedRangeCommandSerializer.deserialize(ReadCommand.java:1042) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.db.ReadCommand$LegacyPagedRangeCommandSerializer.deserialize(ReadCommand.java:964) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at org.apache.cassandra.net.MessageIn.read(MessageIn.java:98) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:201) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:178) > ~[apache-cassandra-3.0.8.jar:3.0.8] > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:92) > ~[apache-cassandra-3.0.8.jar:3.0.8] > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12167) Review JMX metrics test coverage
[ https://issues.apache.org/jira/browse/CASSANDRA-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12167: Labels: (was: dtest) > Review JMX metrics test coverage > > > Key: CASSANDRA-12167 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12167 > Project: Cassandra > Issue Type: Test >Reporter: Jim Witschey >Assignee: DS Test Eng > > I just deleted the dtest that was meant to smoke test JMX metrics: > https://github.com/riptano/cassandra-dtest/pull/1085 > The idea was that you'd read JMX metrics, run stress, then make sure the > metrics went up, down, or stayed the same, as appropriate. This kind of > coverage would be good to have. > I don't think we have it anywhere in the dtests, and it probably isn't > appropriate in unit tests. We should check there's no coverage in the unit > tests, and add some coverage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11237) Nodetool dtest testing gaps
[ https://issues.apache.org/jira/browse/CASSANDRA-11237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-11237: Labels: (was: dtest) > Nodetool dtest testing gaps > --- > > Key: CASSANDRA-11237 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11237 > Project: Cassandra > Issue Type: Test > Components: Testing, Tools >Reporter: Michael Shuler >Assignee: DS Test Eng > > cassandra-dtest has one dedicated nodetool_test.py suite that contains a > small number of tests, and the nodetool utility itself is used throughout > cassandra-dtest, as needed. I've searched through dtest for the nodetool > commands that are / are not used in tests and compiled a spreadsheet of the > commands available in each of the active branches and their use in dtests, as > off dtest commit 733e3c9 - Feb 23, 2016. > This sheet should allow public view/comments. > https://docs.google.com/spreadsheets/d/1R1V2C2JfOq84BhLuRrfXmURIhmyngpGz9KuNw7mqWB0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12137) dtest failure in sstable_generation_loading_test.TestSSTableGenerationAndLoading.sstableloader_compression_deflate_to_snappy_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12137: Assignee: Jim Witschey (was: DS Test Eng) > dtest failure in > sstable_generation_loading_test.TestSSTableGenerationAndLoading.sstableloader_compression_deflate_to_snappy_test > - > > Key: CASSANDRA-12137 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12137 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: Jim Witschey > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.0_dtest/764/testReport/sstable_generation_loading_test/TestSSTableGenerationAndLoading/sstableloader_compression_deflate_to_snappy_test > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/sstable_generation_loading_test.py", > line 75, in sstableloader_compression_deflate_to_snappy_test > self.load_sstable_with_configuration('Deflate', 'Snappy') > File "/home/automaton/cassandra-dtest/sstable_generation_loading_test.py", > line 178, in load_sstable_with_configuration > "sstableloader exited with a non-zero status: {}".format(exit_status)) > File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual > assertion_func(first, second, msg=msg) > File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual > raise self.failureException(msg) > "sstableloader exited with a non-zero status: 1 > {code} > Related failures: > http://cassci.datastax.com/job/cassandra-3.0_dtest/764/testReport/sstable_generation_loading_test/TestSSTableGenerationAndLoading/sstableloader_compression_none_to_snappy_test/ > http://cassci.datastax.com/job/cassandra-3.0_dtest/764/testReport/sstable_generation_loading_test/TestSSTableGenerationAndLoading/sstableloader_with_mv_test/ > Failed on CassCI build cassandra-3.0_dtest #764 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12162) dtest failure in repair_tests.repair_test.TestRepair.simple_sequential_repair_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12162: Labels: dtest windows (was: dtest) > dtest failure in > repair_tests.repair_test.TestRepair.simple_sequential_repair_test > -- > > Key: CASSANDRA-12162 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12162 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: DS Test Eng > Labels: dtest, windows > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.2_dtest_win32/267/testReport/repair_tests.repair_test/TestRepair/simple_sequential_repair_test > Failed on CassCI build cassandra-2.2_dtest_win32 #267 > {code} > Stacktrace > File "C:\tools\python2\lib\unittest\case.py", line 329, in run > testMethod() > File > "D:\jenkins\workspace\cassandra-2.2_dtest_win32\cassandra-dtest\repair_tests\repair_test.py", > line 241, in simple_sequential_repair_test > self._simple_repair(sequential=True) > File > "D:\jenkins\workspace\cassandra-2.2_dtest_win32\cassandra-dtest\repair_tests\repair_test.py", > line 295, in _simple_repair > self._populate_cluster() > File > "D:\jenkins\workspace\cassandra-2.2_dtest_win32\cassandra-dtest\repair_tests\repair_test.py", > line 98, in _populate_cluster > insert_c1c2(session, n=1000, consistency=ConsistencyLevel.ALL) > File > "D:\jenkins\workspace\cassandra-2.2_dtest_win32\cassandra-dtest\tools.py", > line 78, in insert_c1c2 > execute_concurrent_with_args(session, statement, [['k{}'.format(k)] for k > in keys]) > File "cassandra\concurrent.py", line 224, in > cassandra.concurrent.execute_concurrent_with_args > (cassandra/concurrent.c:5996) > return execute_concurrent(session, zip(cycle((statement,)), parameters), > *args, **kwargs) > File "cassandra\concurrent.py", line 92, in > cassandra.concurrent.execute_concurrent (cassandra/concurrent.c:1455) > return executor.execute(concurrency, raise_on_first_error) > File "cassandra\concurrent.py", line 187, in > cassandra.concurrent.ConcurrentExecutorListResults.execute > (cassandra/concurrent.c:4824) > return super(ConcurrentExecutorListResults, self).execute(concurrency, > fail_fast) > File "cassandra\concurrent.py", line 115, in > cassandra.concurrent._ConcurrentExecutor.execute (cassandra/concurrent.c:2120) > return self._results() > File "cassandra\concurrent.py", line 201, in > cassandra.concurrent.ConcurrentExecutorListResults._results > (cassandra/concurrent.c:5617) > with self._condition: > File "cassandra\concurrent.py", line 205, in > cassandra.concurrent.ConcurrentExecutorListResults._results > (cassandra/concurrent.c:5549) > self._raise(self._exception) > File "cassandra\concurrent.py", line 153, in > cassandra.concurrent._ConcurrentExecutor._raise (cassandra/concurrent.c:3498) > raise exc > 'Error from server: code=1500 [Replica(s) failed to execute write] > message="Operation failed - received 2 responses and 1 failures" > info={\'failures\': 1, \'received_responses\': 2, \'required_responses\': 3, > \'consistency\': \'ALL\'} > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12196) dtest failure in upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_2_1_x_To_indev_3_x.bootstrap_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412087#comment-15412087 ] Philip Thompson commented on CASSANDRA-12196: - So, this failure is still occurring over in large dtest > dtest failure in > upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_2_1_x_To_indev_3_x.bootstrap_test > -- > > Key: CASSANDRA-12196 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12196 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: DS Test Eng > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log, > node4.log, node4_debug.log, node4_gc.log > > > example failure: > http://cassci.datastax.com/job/upgrade_tests-all/59/testReport/upgrade_tests.upgrade_through_versions_test/TestUpgrade_current_2_1_x_To_indev_3_x/bootstrap_test > Failed on CassCI build upgrade_tests-all #59 > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File > "/home/automaton/cassandra-dtest/upgrade_tests/upgrade_through_versions_test.py", > line 707, in bootstrap_test > self.upgrade_scenario(after_upgrade_call=(self._bootstrap_new_node,)) > File > "/home/automaton/cassandra-dtest/upgrade_tests/upgrade_through_versions_test.py", > line 383, in upgrade_scenario > call() > File > "/home/automaton/cassandra-dtest/upgrade_tests/upgrade_through_versions_test.py", > line 688, in _bootstrap_new_node > nnode.start(use_jna=True, wait_other_notice=True, > wait_for_binary_proto=True) > File "/home/automaton/ccm/ccmlib/node.py", line 634, in start > node.watch_log_for_alive(self, from_mark=mark) > File "/home/automaton/ccm/ccmlib/node.py", line 481, in watch_log_for_alive > self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout, > filename=filename) > File "/home/automaton/ccm/ccmlib/node.py", line 449, in watch_log_for > raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + " > [" + self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" + > reads[:50] + ".\nSee {} for remainder".format(filename)) > "13 Jul 2016 02:23:05 [node2] Missing: ['127.0.0.4.* now UP']:\nINFO > [HANDSHAKE-/127.0.0.4] 2016-07-13 02:21:00,2.\nSee system.log for > remainder > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12225) dtest failure in materialized_views_test.TestMaterializedViews.clustering_column_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412079#comment-15412079 ] Philip Thompson commented on CASSANDRA-12225: - Bump, [~carlyeks], can you clarify what you meant by flakey test? > dtest failure in > materialized_views_test.TestMaterializedViews.clustering_column_test > - > > Key: CASSANDRA-12225 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12225 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: DS Test Eng > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log > > > example failure: > http://cassci.datastax.com/job/trunk_offheap_dtest/336/testReport/materialized_views_test/TestMaterializedViews/clustering_column_test > Failed on CassCI build trunk_offheap_dtest #336 > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/materialized_views_test.py", line > 321, in clustering_column_test > self.assertEqual(len(result), 2, "Expecting {} users, got {}".format(2, > len(result))) > File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual > assertion_func(first, second, msg=msg) > File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual > raise self.failureException(msg) > "Expecting 2 users, got 1 > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12316) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_round_trip_random
[ https://issues.apache.org/jira/browse/CASSANDRA-12316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412074#comment-15412074 ] Philip Thompson edited comment on CASSANDRA-12316 at 8/8/16 4:57 PM: - Because there is a second failure for this test, where it fails to collect the system.log, implying the node never came up. However, it didnt show up in the multiplex, or again, so I'll close as the driver issue was (Author: philipthompson): Because there is a second failure for this test, where it fails to collect the system.log, implying the node never came up > dtest failure in > cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_round_trip_random > -- > > Key: CASSANDRA-12316 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12316 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/16/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_round_trip_random -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12316) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_round_trip_random
[ https://issues.apache.org/jira/browse/CASSANDRA-12316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson resolved CASSANDRA-12316. - Resolution: Cannot Reproduce > dtest failure in > cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_round_trip_random > -- > > Key: CASSANDRA-12316 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12316 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/16/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_round_trip_random -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12316) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_round_trip_random
[ https://issues.apache.org/jira/browse/CASSANDRA-12316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412074#comment-15412074 ] Philip Thompson commented on CASSANDRA-12316: - Because there is a second failure for this test, where it fails to collect the system.log, implying the node never came up > dtest failure in > cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_round_trip_random > -- > > Key: CASSANDRA-12316 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12316 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/16/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_round_trip_random -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12352) dtest failure in upgrade_tests.storage_engine_upgrade_test.TestLoadLaCompactSStables.sstableloader_compression_snappy_to_snappy_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson resolved CASSANDRA-12352. - Resolution: Cannot Reproduce Yeah these were all resolved by the driver fix. > dtest failure in > upgrade_tests.storage_engine_upgrade_test.TestLoadLaCompactSStables.sstableloader_compression_snappy_to_snappy_test > > > Key: CASSANDRA-12352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12352 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: DS Test Eng > Labels: dtest > Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log > > > These are all similar looking test failures, which appear to be timeout > issues of some kind. > {noformat}('Unable to connect to any servers', {'127.0.0.1': > OperationTimedOut('errors=Timed out creating connection (10 seconds), > last_host=None',)}){noformat} > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.storage_engine_upgrade_test/TestLoadLaCompactSStables/sstableloader_compression_snappy_to_snappy_test > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.storage_engine_upgrade_test/TestLoadLaSStables/sstableloader_compression_deflate_to_deflate_test/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDataNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x/test_paging_across_multi_wide_rows/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDataNodes3RF3_Upgrade_current_2_1_x_To_indev_3_0_x/test_paging_across_multi_wide_rows/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingSizeNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x/test_undefined_page_size_default/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_Upgrade_current_2_1_x_To_indev_3_0_x/test_cell_TTL_expiry_during_paging/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingSizeNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x/test_undefined_page_size_default/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes2RF1_Upgrade_current_3_0_x_To_indev_3_0_x/test_cell_TTL_expiry_during_paging/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x/test_row_TTL_expiry_during_paging/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.storage_engine_upgrade_test/TestBootstrapAfterUpgrade/upgrade_with_unclustered_CQL_table_test/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_3_0_x/range_tombstones_compaction_test/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_3_0_x_To_indev_3_0_x/bug_5732_test/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_3_0_x/collection_flush_test/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_3_0_x_To_indev_3_0_x/large_count_test/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x/conditional_delete_test/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x/range_tombstones_compaction_test/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingWithDeletionsNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x/test_failure_threshold_deletions/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.paging_test/TestPagingWithDeletionsNodes2RF1_Upgrade_current_3_0_x_To_indev_3_0_x/test_ttl_deletions/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_3_0_x/limit_multiget_test/ > http://cassci.datastax.com/job/cassandra-3.0_dtest_upgrade/10/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_1_x_To_indev_3_0_x/limit_multiget_test/ > http://cassc
[jira] [Created] (CASSANDRA-12411) Do not store passwords in .cassandra/cqlsh_history
jonathan lacefield created CASSANDRA-12411: -- Summary: Do not store passwords in .cassandra/cqlsh_history Key: CASSANDRA-12411 URL: https://issues.apache.org/jira/browse/CASSANDRA-12411 Project: Cassandra Issue Type: Improvement Components: Core Reporter: jonathan lacefield This is a request to ensure that passwords are not stored in the cqlsh_history file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12205) nodetool tablestats sstable count missing.
[ https://issues.apache.org/jira/browse/CASSANDRA-12205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412037#comment-15412037 ] Joshua McKenzie commented on CASSANDRA-12205: - [~cam888eron]: That was an oversight on my part. When I re-opened the issue I neglected to delete the JIRA link indicating the incorrect duplication. Sorry for the confusion. > nodetool tablestats sstable count missing. > -- > > Key: CASSANDRA-12205 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12205 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Cassandra 3.7 >Reporter: Cameron MacMinn >Assignee: Edward Ribeiro > Fix For: 3.9 > > Attachments: CASSANDRA-12205.patch, bad.txt, good.txt > > > As a user, I have used nodetool cfstats since v2.1. The most useful line is > the 1 like 'SSTable count: 12'. > As a user, I want v3.7 nodetool tablestats to continue showing SStable > count. At the moment, SStable count is missing from the output. > Examples attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12407) dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412028#comment-15412028 ] Philip Thompson commented on CASSANDRA-12407: - [~thobbs], this is a follow up from CASSANDRA-11598. It seems that basically every part of this test is flaky on 2.1. Should we just skip it before 2.2? > dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test > > > Key: CASSANDRA-12407 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12407 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: Philip Thompson > Labels: dtest > Attachments: node1.log, node2.log, node3.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/381/testReport/cql_tracing_test/TestCqlTracing/tracing_simple_test > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 102, in > tracing_simple_test > self.trace(session) > File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 74, in > trace > self.assertIn('/127.0.0.1', out) > File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn > self.fail(self._formatMessage(msg, standardMsg)) > File "/usr/lib/python2.7/unittest/case.py", line 410, in fail > raise self.failureException(msg) > '\'/127.0.0.1\' not found in "Consistency level set to ALL. > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12008) Make decommission operations resumable
[ https://issues.apache.org/jira/browse/CASSANDRA-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412014#comment-15412014 ] Paulo Motta commented on CASSANDRA-12008: - Thanks for the update. I think it looks good now! I submitted a few test runs (below), and if these look good you can go ahead and open the PR. bq. You mean that I have to rebase my remote branch? yes, normally before committing you do a git-rebase on top of the updated remote branch and also squash multiple commits into a single commit. I did this in the implementation and dtests branches below, and also submitted cstar test runs: ||trunk||dtest|| |[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-12008]|[branch|https://github.com/riptano/cassandra-dtest/compare/master...pauloricardomg:12008]| |[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-12008-testall/lastCompletedBuild/testReport/]| |[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-12008-dtest/lastCompletedBuild/testReport/]| |[multiplexer resumable_decommission_test|https://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/219/]| |[multiplexer concurrent_decommission_not_allowed_test|https://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/220/]| > Make decommission operations resumable > -- > > Key: CASSANDRA-12008 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12008 > Project: Cassandra > Issue Type: Improvement > Components: Streaming and Messaging >Reporter: Tom van der Woerdt >Assignee: Kaide Mu >Priority: Minor > > We're dealing with large data sets (multiple terabytes per node) and > sometimes we need to add or remove nodes. These operations are very dependent > on the entire cluster being up, so while we're joining a new node (which > sometimes takes 6 hours or longer) a lot can go wrong and in a lot of cases > something does. > It would be great if the ability to retry streams was implemented. > Example to illustrate the problem : > {code} > 03:18 PM ~ $ nodetool decommission > error: Stream failed > -- StackTrace -- > org.apache.cassandra.streaming.StreamException: Stream failed > at > org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85) > at com.google.common.util.concurrent.Futures$6.run(Futures.java:1310) > at > com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457) > at > com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156) > at > com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145) > at > com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202) > at > org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:210) > at > org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:186) > at > org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:430) > at > org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:622) > at > org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:486) > at > org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:274) > at java.lang.Thread.run(Thread.java:745) > 08:04 PM ~ $ nodetool decommission > nodetool: Unsupported operation: Node in LEAVING state; wait for status to > become normal or restart > See 'nodetool help' or 'nodetool help '. > {code} > Streaming failed, probably due to load : > {code} > ERROR [STREAM-IN-/] 2016-06-14 18:05:47,275 StreamSession.java:520 - > [Stream #] Streaming error occurred > java.net.SocketTimeoutException: null > at > sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:211) > ~[na:1.8.0_77] > at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) > ~[na:1.8.0_77] > at > java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:385) > ~[na:1.8.0_77] > at > org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:54) > ~[apache-cassandra-3.0.6.jar:3.0.6] > at > org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:268) > ~[apache-cassandra-3.0.6.jar:3.0.6] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_77] > {code} > If implementing retries is not possible, can we have a 'nodetool decommission > resume'? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12246) Cassandra v2.2 to v3.0.9 upgrade failed
[ https://issues.apache.org/jira/browse/CASSANDRA-12246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412000#comment-15412000 ] Jeremiah Jordan commented on CASSANDRA-12246: - [~bistory] what is your schema pre upgrade? Can you attach the output of "DESCRIBE SCHEMA;" from cqlsh as well as a "SELECT * FROM " for the following tables: system.schema_columnfamilies system.schema_columns system.schema_keyspaces > Cassandra v2.2 to v3.0.9 upgrade failed > --- > > Key: CASSANDRA-12246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12246 > Project: Cassandra > Issue Type: Bug > Environment: Ubuntu 14.04, DSC 2.2 > DSC 3.0 >Reporter: Thomas Lété >Assignee: Aleksey Yeschenko > Fix For: 3.0.9 > > > Hi, > I'm trying to upgrade our Cassandra cluster which has been created using > opscenter. > Now that Opscenter dropped support for Datastax Community, upgraded manually. > Unfortunately, the Schema Migrator seems to hang somewhere during startup. > Here is the log I get : > {code:title=debug.log} > INFO [main] 2016-07-20 15:34:49,381 SystemKeyspace.java:1283 - Detected > version upgrade from 2.2.7 to 3.0.8, snapshotting system keyspace > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,383 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > compaction_history > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,389 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > hints > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,389 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_aggregates > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,392 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > IndexInfo > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,393 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_columnfamilies > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,395 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_triggers > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,398 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > size_estimates > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,401 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_functions > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,403 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > paxos > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,404 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > views_builds_in_progress > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,404 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > built_views > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,405 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > peer_events > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,405 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > range_xfers > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,406 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > peers > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,408 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > batches > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,408 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_keyspaces > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,410 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_usertypes > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,413 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > local > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,415 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > sstable_activity > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,418 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > available_ranges > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,418 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > batchlog > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,418 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_columns > WARN [main] 2016-07-20 15:34:49,634 CompressionParams.java:382 - The > sstable_compression option has been deprecated. You should use class instead > WARN [main] 2016-07-20 15:34:49,654 CompressionParams.java:333 - The > chunk_length_kb option has been deprecated. You should use chunk_length_i
[jira] [Comment Edited] (CASSANDRA-12246) Cassandra v2.2 to v3.0.9 upgrade failed
[ https://issues.apache.org/jira/browse/CASSANDRA-12246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412000#comment-15412000 ] Jeremiah Jordan edited comment on CASSANDRA-12246 at 8/8/16 4:00 PM: - [~bistory] what is your schema pre upgrade? Can you attach the output of "DESCRIBE SCHEMA;" from cqlsh as well as a "SELECT * FROM " for the following tables: system.schema_columnfamilies system.schema_columns system.schema_keyspaces >From a node that is running Cassandra 2.2 was (Author: jjordan): [~bistory] what is your schema pre upgrade? Can you attach the output of "DESCRIBE SCHEMA;" from cqlsh as well as a "SELECT * FROM " for the following tables: system.schema_columnfamilies system.schema_columns system.schema_keyspaces > Cassandra v2.2 to v3.0.9 upgrade failed > --- > > Key: CASSANDRA-12246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12246 > Project: Cassandra > Issue Type: Bug > Environment: Ubuntu 14.04, DSC 2.2 > DSC 3.0 >Reporter: Thomas Lété >Assignee: Aleksey Yeschenko > Fix For: 3.0.9 > > > Hi, > I'm trying to upgrade our Cassandra cluster which has been created using > opscenter. > Now that Opscenter dropped support for Datastax Community, upgraded manually. > Unfortunately, the Schema Migrator seems to hang somewhere during startup. > Here is the log I get : > {code:title=debug.log} > INFO [main] 2016-07-20 15:34:49,381 SystemKeyspace.java:1283 - Detected > version upgrade from 2.2.7 to 3.0.8, snapshotting system keyspace > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,383 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > compaction_history > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,389 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > hints > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,389 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_aggregates > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,392 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > IndexInfo > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,393 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_columnfamilies > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,395 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_triggers > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,398 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > size_estimates > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,401 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_functions > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,403 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > paxos > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,404 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > views_builds_in_progress > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,404 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > built_views > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,405 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > peer_events > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,405 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > range_xfers > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,406 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > peers > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,408 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > batches > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,408 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_keyspaces > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,410 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > schema_usertypes > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,413 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > local > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,415 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > sstable_activity > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,418 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > available_ranges > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,418 > ColumnFamilyStore.java:898 - forceFlush requested but everything is clean in > batchlog > DEBUG [MemtablePostFlush:1] 2016-07-20 15:34:49,418 > ColumnFamilyStore.java:898 - forceFlush req
[jira] [Commented] (CASSANDRA-12167) Review JMX metrics test coverage
[ https://issues.apache.org/jira/browse/CASSANDRA-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411987#comment-15411987 ] Philip Thompson commented on CASSANDRA-12167: - Seems reasonable then > Review JMX metrics test coverage > > > Key: CASSANDRA-12167 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12167 > Project: Cassandra > Issue Type: Test >Reporter: Jim Witschey >Assignee: DS Test Eng > Labels: dtest > > I just deleted the dtest that was meant to smoke test JMX metrics: > https://github.com/riptano/cassandra-dtest/pull/1085 > The idea was that you'd read JMX metrics, run stress, then make sure the > metrics went up, down, or stayed the same, as appropriate. This kind of > coverage would be good to have. > I don't think we have it anywhere in the dtests, and it probably isn't > appropriate in unit tests. We should check there's no coverage in the unit > tests, and add some coverage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12406) dtest failure in pushed_notifications_test.TestPushedNotifications.move_single_node_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411984#comment-15411984 ] Philip Thompson commented on CASSANDRA-12406: - Looks like an extra NEW_NODE is being sent, here > dtest failure in > pushed_notifications_test.TestPushedNotifications.move_single_node_test > > > Key: CASSANDRA-12406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12406 > Project: Cassandra > Issue Type: Bug >Reporter: Sean McCarthy > Labels: dtest > Fix For: 2.1.x > > Attachments: node1.log, node2.log, node3.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/271/testReport/pushed_notifications_test/TestPushedNotifications/move_single_node_test > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/pushed_notifications_test.py", line > 110, in move_single_node_test > self.assertEquals(1, len(notifications), notifications) > File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual > assertion_func(first, second, msg=msg) > File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual > raise self.failureException(msg) > "[{'change_type': u'MOVED_NODE', 'address': ('127.0.0.1', 9042)}, > {'change_type': u'NEW_NODE', 'address': ('127.0.0.1', 9042)}] > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12406) dtest failure in pushed_notifications_test.TestPushedNotifications.move_single_node_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12406: Fix Version/s: 2.1.x > dtest failure in > pushed_notifications_test.TestPushedNotifications.move_single_node_test > > > Key: CASSANDRA-12406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12406 > Project: Cassandra > Issue Type: Bug >Reporter: Sean McCarthy > Labels: dtest > Fix For: 2.1.x > > Attachments: node1.log, node2.log, node3.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/271/testReport/pushed_notifications_test/TestPushedNotifications/move_single_node_test > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/pushed_notifications_test.py", line > 110, in move_single_node_test > self.assertEquals(1, len(notifications), notifications) > File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual > assertion_func(first, second, msg=msg) > File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual > raise self.failureException(msg) > "[{'change_type': u'MOVED_NODE', 'address': ('127.0.0.1', 9042)}, > {'change_type': u'NEW_NODE', 'address': ('127.0.0.1', 9042)}] > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12406) dtest failure in pushed_notifications_test.TestPushedNotifications.move_single_node_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12406: Assignee: (was: DS Test Eng) > dtest failure in > pushed_notifications_test.TestPushedNotifications.move_single_node_test > > > Key: CASSANDRA-12406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12406 > Project: Cassandra > Issue Type: Bug >Reporter: Sean McCarthy > Labels: dtest > Fix For: 2.1.x > > Attachments: node1.log, node2.log, node3.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/271/testReport/pushed_notifications_test/TestPushedNotifications/move_single_node_test > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/pushed_notifications_test.py", line > 110, in move_single_node_test > self.assertEquals(1, len(notifications), notifications) > File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual > assertion_func(first, second, msg=msg) > File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual > raise self.failureException(msg) > "[{'change_type': u'MOVED_NODE', 'address': ('127.0.0.1', 9042)}, > {'change_type': u'NEW_NODE', 'address': ('127.0.0.1', 9042)}] > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12406) dtest failure in pushed_notifications_test.TestPushedNotifications.move_single_node_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12406: Issue Type: Bug (was: Test) > dtest failure in > pushed_notifications_test.TestPushedNotifications.move_single_node_test > > > Key: CASSANDRA-12406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12406 > Project: Cassandra > Issue Type: Bug >Reporter: Sean McCarthy >Assignee: DS Test Eng > Labels: dtest > Fix For: 2.1.x > > Attachments: node1.log, node2.log, node3.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/271/testReport/pushed_notifications_test/TestPushedNotifications/move_single_node_test > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/pushed_notifications_test.py", line > 110, in move_single_node_test > self.assertEquals(1, len(notifications), notifications) > File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual > assertion_func(first, second, msg=msg) > File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual > raise self.failureException(msg) > "[{'change_type': u'MOVED_NODE', 'address': ('127.0.0.1', 9042)}, > {'change_type': u'NEW_NODE', 'address': ('127.0.0.1', 9042)}] > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12167) Review JMX metrics test coverage
[ https://issues.apache.org/jira/browse/CASSANDRA-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411981#comment-15411981 ] Jim Witschey commented on CASSANDRA-12167: -- Sounds right -- but, I think that the documentation on these was fleshed out much better, which could make it more doable for TE. Thoughts? > Review JMX metrics test coverage > > > Key: CASSANDRA-12167 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12167 > Project: Cassandra > Issue Type: Test >Reporter: Jim Witschey >Assignee: DS Test Eng > Labels: dtest > > I just deleted the dtest that was meant to smoke test JMX metrics: > https://github.com/riptano/cassandra-dtest/pull/1085 > The idea was that you'd read JMX metrics, run stress, then make sure the > metrics went up, down, or stayed the same, as appropriate. This kind of > coverage would be good to have. > I don't think we have it anywhere in the dtests, and it probably isn't > appropriate in unit tests. We should check there's no coverage in the unit > tests, and add some coverage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12408) dtest failure in upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x.select_with_alias_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12408: Resolution: Fixed Status: Resolved (was: Patch Available) > dtest failure in > upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x.select_with_alias_test > - > > Key: CASSANDRA-12408 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12408 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: Philip Thompson > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x/select_with_alias_test > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/upgrade_tests/cql_tests.py", line > 3187, in select_with_alias_test > assert_invalid(cursor, 'SELECT id AS user_id, name AS user_name FROM > users WHERE id IN (0) ORDER BY user_name', matching=error_msg) > File "/home/automaton/cassandra-dtest/assertions.py", line 92, in > assert_invalid > assert_exception(session, query, matching=matching, expected=expected) > File "/home/automaton/cassandra-dtest/assertions.py", line 65, in > assert_exception > _assert_exception(session.execute, query, matching=matching, > expected=expected) > File "/home/automaton/cassandra-dtest/assertions.py", line 54, in > _assert_exception > assert_regexp_matches(str(e), matching) > File "/usr/lib/python2.7/unittest/case.py", line 1002, in > assertRegexpMatches > raise self.failureException(msg) > 'Regexp didn\'t match: "Aliases aren\'t allowed in the where clause" not > found in \'Error from server: code=2200 [Invalid query] message="Aliases are > not allowed in order by clause (\\\'user_name\\\')"\' > {code} > Related failures: > http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_0_x_To_indev_2_1_x/select_with_alias_test/ > http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_0_x_To_indev_2_1_x/select_with_alias_test/ > http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_1_x_To_indev_2_1_x/select_with_alias_test/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12408) dtest failure in upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x.select_with_alias_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12408: Reviewer: Sean McCarthy Status: Patch Available (was: In Progress) https://github.com/riptano/cassandra-dtest/pull/1188 > dtest failure in > upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x.select_with_alias_test > - > > Key: CASSANDRA-12408 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12408 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: Philip Thompson > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x/select_with_alias_test > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/upgrade_tests/cql_tests.py", line > 3187, in select_with_alias_test > assert_invalid(cursor, 'SELECT id AS user_id, name AS user_name FROM > users WHERE id IN (0) ORDER BY user_name', matching=error_msg) > File "/home/automaton/cassandra-dtest/assertions.py", line 92, in > assert_invalid > assert_exception(session, query, matching=matching, expected=expected) > File "/home/automaton/cassandra-dtest/assertions.py", line 65, in > assert_exception > _assert_exception(session.execute, query, matching=matching, > expected=expected) > File "/home/automaton/cassandra-dtest/assertions.py", line 54, in > _assert_exception > assert_regexp_matches(str(e), matching) > File "/usr/lib/python2.7/unittest/case.py", line 1002, in > assertRegexpMatches > raise self.failureException(msg) > 'Regexp didn\'t match: "Aliases aren\'t allowed in the where clause" not > found in \'Error from server: code=2200 [Invalid query] message="Aliases are > not allowed in order by clause (\\\'user_name\\\')"\' > {code} > Related failures: > http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_0_x_To_indev_2_1_x/select_with_alias_test/ > http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_0_x_To_indev_2_1_x/select_with_alias_test/ > http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_1_x_To_indev_2_1_x/select_with_alias_test/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12408) dtest failure in upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x.select_with_alias_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson reassigned CASSANDRA-12408: --- Assignee: Philip Thompson (was: DS Test Eng) > dtest failure in > upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x.select_with_alias_test > - > > Key: CASSANDRA-12408 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12408 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: Philip Thompson > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x/select_with_alias_test > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/upgrade_tests/cql_tests.py", line > 3187, in select_with_alias_test > assert_invalid(cursor, 'SELECT id AS user_id, name AS user_name FROM > users WHERE id IN (0) ORDER BY user_name', matching=error_msg) > File "/home/automaton/cassandra-dtest/assertions.py", line 92, in > assert_invalid > assert_exception(session, query, matching=matching, expected=expected) > File "/home/automaton/cassandra-dtest/assertions.py", line 65, in > assert_exception > _assert_exception(session.execute, query, matching=matching, > expected=expected) > File "/home/automaton/cassandra-dtest/assertions.py", line 54, in > _assert_exception > assert_regexp_matches(str(e), matching) > File "/usr/lib/python2.7/unittest/case.py", line 1002, in > assertRegexpMatches > raise self.failureException(msg) > 'Regexp didn\'t match: "Aliases aren\'t allowed in the where clause" not > found in \'Error from server: code=2200 [Invalid query] message="Aliases are > not allowed in order by clause (\\\'user_name\\\')"\' > {code} > Related failures: > http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_0_x_To_indev_2_1_x/select_with_alias_test/ > http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_0_x_To_indev_2_1_x/select_with_alias_test/ > http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_1_x_To_indev_2_1_x/select_with_alias_test/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12410) dtest failure in upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_2_2_x_To_indev_3_x.bootstrap_multidc_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411952#comment-15411952 ] Sean McCarthy commented on CASSANDRA-12410: --- Duplicate of CASSANDRA-12140 > dtest failure in > upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_2_2_x_To_indev_3_x.bootstrap_multidc_test > -- > > Key: CASSANDRA-12410 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12410 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_large_dtest/7/testReport/upgrade_tests.upgrade_through_versions_test/TestUpgrade_current_2_2_x_To_indev_3_x/bootstrap_multidc_test > {code} > node5: ERROR [main] 2016-08-06 18:38:38,187 MigrationManager.java:164 - > Migration task failed to complete > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12410) dtest failure in upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_2_2_x_To_indev_3_x.bootstrap_multidc_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean McCarthy resolved CASSANDRA-12410. --- Resolution: Duplicate > dtest failure in > upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_2_2_x_To_indev_3_x.bootstrap_multidc_test > -- > > Key: CASSANDRA-12410 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12410 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_large_dtest/7/testReport/upgrade_tests.upgrade_through_versions_test/TestUpgrade_current_2_2_x_To_indev_3_x/bootstrap_multidc_test > {code} > node5: ERROR [main] 2016-08-06 18:38:38,187 MigrationManager.java:164 - > Migration task failed to complete > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12410) dtest failure in upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_2_2_x_To_indev_3_x.bootstrap_multidc_test
Sean McCarthy created CASSANDRA-12410: - Summary: dtest failure in upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_2_2_x_To_indev_3_x.bootstrap_multidc_test Key: CASSANDRA-12410 URL: https://issues.apache.org/jira/browse/CASSANDRA-12410 Project: Cassandra Issue Type: Test Reporter: Sean McCarthy Assignee: DS Test Eng example failure: http://cassci.datastax.com/job/cassandra-3.9_large_dtest/7/testReport/upgrade_tests.upgrade_through_versions_test/TestUpgrade_current_2_2_x_To_indev_3_x/bootstrap_multidc_test {code} node5: ERROR [main] 2016-08-06 18:38:38,187 MigrationManager.java:164 - Migration task failed to complete {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12393) dtest failure in bootstrap_test.TestBootstrap.local_quorum_bootstrap_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12393: Resolution: Fixed Status: Resolved (was: Patch Available) > dtest failure in bootstrap_test.TestBootstrap.local_quorum_bootstrap_test > - > > Key: CASSANDRA-12393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12393 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: Philip Thompson > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.2_dtest/666/testReport/bootstrap_test/TestBootstrap/local_quorum_bootstrap_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12409) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_2_2_x.select_with_alias_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson resolved CASSANDRA-12409. - Resolution: Duplicate > dtest failure in > upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_2_2_x.select_with_alias_test > - > > Key: CASSANDRA-12409 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12409 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-2.2_dtest_upgrade/11/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_2_2_x/select_with_alias_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12064) dtest failure in auth_test.TestAuth.login_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson resolved CASSANDRA-12064. - Resolution: Cannot Reproduce Fix Version/s: (was: 3.9) > dtest failure in auth_test.TestAuth.login_test > -- > > Key: CASSANDRA-12064 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12064 > Project: Cassandra > Issue Type: Test >Reporter: Sean McCarthy >Assignee: DS Test Eng > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log > > > example failure: > http://cassci.datastax.com/job/trunk_dtest/1284/testReport/auth_test/TestAuth/login_test > Failed on CassCI build trunk_dtest #1284 > {code} > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File "/home/automaton/cassandra-dtest/auth_test.py", line 82, in login_test > assert isinstance(e.errors.values()[0], AuthenticationFailed) > {code} > Logs are attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12409) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_2_2_x.select_with_alias_test
Craig Kodman created CASSANDRA-12409: Summary: dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_2_2_x.select_with_alias_test Key: CASSANDRA-12409 URL: https://issues.apache.org/jira/browse/CASSANDRA-12409 Project: Cassandra Issue Type: Test Reporter: Craig Kodman Assignee: DS Test Eng example failure: http://cassci.datastax.com/job/cassandra-2.2_dtest_upgrade/11/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_2_x_To_indev_2_2_x/select_with_alias_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12358) Slow PostFlush execution due to 2i flushing can cause near OOM to OOM
[ https://issues.apache.org/jira/browse/CASSANDRA-12358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15403128#comment-15403128 ] Ariel Weisberg edited comment on CASSANDRA-12358 at 8/8/16 3:18 PM: |[trunk|https://github.com/apache/cassandra/compare/trunk...aweisberg:CASSANDRA-12358-trunk?expand=1]|[utests|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-12358-trunk-testall/3/]|[dtests|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-12358-trunk-dtest/3/]| was (Author: aweisberg): |[trunk|https://github.com/apache/cassandra/compare/trunk...aweisberg:CASSANDRA-12358-trunk?expand=1]|[utests|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-12358-trunk-testall/1/]|[dtests|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-12358-trunk-dtest/1/]| > Slow PostFlush execution due to 2i flushing can cause near OOM to OOM > - > > Key: CASSANDRA-12358 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12358 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Fix For: 3.10 > > > 2i can be slow to flush for a variety of reasons. Potentially slower than the > rate at which Memtables can ingest and flush data. If this occurs the heap > fills up with Memtables that are waiting for PostFlush to run. > This occurs because reclaiming the memory is done before PostFlush runs. > I will post a branch that has the reclaim memory task run after PostFlush has > completed. As far as I can tell this is safe and correct since the memory is > committed up until that point. > It's not clear to me if PostFlush has to bind the Memtables or not. I suspect > it does, but I'm not sure if that is a route I should go down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11909) dtest failure in cql_tests.AbortedQueriesTester.remote_query_test
[ https://issues.apache.org/jira/browse/CASSANDRA-11909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson resolved CASSANDRA-11909. - Resolution: Cannot Reproduce Fix Version/s: (was: 3.9) > dtest failure in cql_tests.AbortedQueriesTester.remote_query_test > - > > Key: CASSANDRA-11909 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11909 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/trunk_dtest/1243/testReport/cql_tests/AbortedQueriesTester/remote_query_test > Failed on CassCI build trunk_dtest #1243 > {code} > ERROR [SharedPool-Worker-1] 2016-05-27 10:08:49,471 Keyspace.java:504 - > Attempting to mutate non-existant table 01855840-23f3-11e6-912e-c5dc3b68cc6d > (ks.test2) > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12408) dtest failure in upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x.select_with_alias_test
Sean McCarthy created CASSANDRA-12408: - Summary: dtest failure in upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x.select_with_alias_test Key: CASSANDRA-12408 URL: https://issues.apache.org/jira/browse/CASSANDRA-12408 Project: Cassandra Issue Type: Test Reporter: Sean McCarthy Assignee: DS Test Eng example failure: http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x/select_with_alias_test {code} Stacktrace File "/usr/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/home/automaton/cassandra-dtest/upgrade_tests/cql_tests.py", line 3187, in select_with_alias_test assert_invalid(cursor, 'SELECT id AS user_id, name AS user_name FROM users WHERE id IN (0) ORDER BY user_name', matching=error_msg) File "/home/automaton/cassandra-dtest/assertions.py", line 92, in assert_invalid assert_exception(session, query, matching=matching, expected=expected) File "/home/automaton/cassandra-dtest/assertions.py", line 65, in assert_exception _assert_exception(session.execute, query, matching=matching, expected=expected) File "/home/automaton/cassandra-dtest/assertions.py", line 54, in _assert_exception assert_regexp_matches(str(e), matching) File "/usr/lib/python2.7/unittest/case.py", line 1002, in assertRegexpMatches raise self.failureException(msg) 'Regexp didn\'t match: "Aliases aren\'t allowed in the where clause" not found in \'Error from server: code=2200 [Invalid query] message="Aliases are not allowed in order by clause (\\\'user_name\\\')"\' {code} Related failures: http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_0_x_To_indev_2_1_x/select_with_alias_test/ http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_0_x_To_indev_2_1_x/select_with_alias_test/ http://cassci.datastax.com/job/cassandra-2.1_dtest_upgrade/6/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_2_1_x_To_indev_2_1_x/select_with_alias_test/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11914) Provide option for cassandra-stress to dump all settings
[ https://issues.apache.org/jira/browse/CASSANDRA-11914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-11914: --- Resolution: Fixed Fix Version/s: (was: 3.x) 3.10 Status: Resolved (was: Awaiting Feedback) There was one dtest failure but it's a known issue unrelated to this change. Committed as {{938faa21697a95d7ec87dccd5750a8a80986509f}} > Provide option for cassandra-stress to dump all settings > > > Key: CASSANDRA-11914 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11914 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Ben Slater >Assignee: Ben Slater >Priority: Minor > Fix For: 3.10 > > > cassandra-stress has quite a lot of default settings and settings that are > derived as side effects of explicit options. For people learning the tool and > saving a clear record of what was run, I think it would be useful if there > was an option to have the tool print all its settings at the start of a run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12393) dtest failure in bootstrap_test.TestBootstrap.local_quorum_bootstrap_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12393: Reviewer: Sean McCarthy Status: Patch Available (was: In Progress) https://github.com/riptano/cassandra-dtest/pull/1185 > dtest failure in bootstrap_test.TestBootstrap.local_quorum_bootstrap_test > - > > Key: CASSANDRA-12393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12393 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: Philip Thompson > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.2_dtest/666/testReport/bootstrap_test/TestBootstrap/local_quorum_bootstrap_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: Cassandra-stress should dump all settings on startup
Repository: cassandra Updated Branches: refs/heads/trunk cee22ad54 -> 938faa216 Cassandra-stress should dump all settings on startup Patch by Ben Slater; reviewed by tjake for CASSANDRA-11914 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/938faa21 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/938faa21 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/938faa21 Branch: refs/heads/trunk Commit: 938faa21697a95d7ec87dccd5750a8a80986509f Parents: cee22ad Author: Ben Slater Authored: Fri Jul 29 15:52:43 2016 +1000 Committer: T Jake Luciani Committed: Mon Aug 8 11:07:05 2016 -0400 -- CHANGES.txt | 1 + .../src/org/apache/cassandra/stress/Stress.java | 9 +- .../apache/cassandra/stress/StressProfile.java | 107 --- .../org/apache/cassandra/stress/StressYaml.java | 8 ++ .../stress/generate/DistributionFactory.java| 1 + .../generate/RatioDistributionFactory.java | 1 + .../stress/generate/values/GeneratorConfig.java | 14 +++ .../stress/settings/GroupedOptions.java | 14 +++ .../cassandra/stress/settings/Option.java | 1 + .../stress/settings/OptionAnyProbabilities.java | 18 .../stress/settings/OptionDistribution.java | 27 + .../cassandra/stress/settings/OptionMulti.java | 26 + .../settings/OptionRatioDistribution.java | 9 ++ .../cassandra/stress/settings/OptionSimple.java | 14 +++ .../stress/settings/SettingsColumn.java | 19 .../stress/settings/SettingsCommand.java| 22 .../settings/SettingsCommandPreDefined.java | 10 ++ .../SettingsCommandPreDefinedMixed.java | 10 ++ .../stress/settings/SettingsCommandUser.java| 13 +++ .../stress/settings/SettingsErrors.java | 8 ++ .../stress/settings/SettingsGraph.java | 11 ++ .../stress/settings/SettingsInsert.java | 32 ++ .../cassandra/stress/settings/SettingsLog.java | 15 ++- .../cassandra/stress/settings/SettingsMode.java | 21 +++- .../cassandra/stress/settings/SettingsNode.java | 7 ++ .../stress/settings/SettingsPopulation.java | 21 .../cassandra/stress/settings/SettingsPort.java | 9 ++ .../cassandra/stress/settings/SettingsRate.java | 15 +++ .../stress/settings/SettingsSchema.java | 13 +++ .../stress/settings/SettingsTokenRange.java | 10 ++ .../stress/settings/SettingsTransport.java | 5 + .../stress/settings/StressSettings.java | 49 + 32 files changed, 500 insertions(+), 40 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/938faa21/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 6fdc04a..097e9c1 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.10 + * Cassandra stress should dump all setting on startup (CASSANDRA-11914) * Make it possible to compact a given token range (CASSANDRA-10643) * Allow updating DynamicEndpointSnitch properties via JMX (CASSANDRA-12179) * Collect metrics on queries by consistency level (CASSANDRA-7384) http://git-wip-us.apache.org/repos/asf/cassandra/blob/938faa21/tools/stress/src/org/apache/cassandra/stress/Stress.java -- diff --git a/tools/stress/src/org/apache/cassandra/stress/Stress.java b/tools/stress/src/org/apache/cassandra/stress/Stress.java index 50b1b81..581ec0c 100644 --- a/tools/stress/src/org/apache/cassandra/stress/Stress.java +++ b/tools/stress/src/org/apache/cassandra/stress/Stress.java @@ -86,7 +86,14 @@ public final class Stress } MultiPrintStream logout = settings.log.getOutput(); -if (settings.graph.inGraphMode()) { + +if (! settings.log.noSettings) +{ +settings.printSettings(logout); +} + +if (settings.graph.inGraphMode()) +{ logout.addStream(new PrintStream(settings.graph.temporaryLogFile)); } http://git-wip-us.apache.org/repos/asf/cassandra/blob/938faa21/tools/stress/src/org/apache/cassandra/stress/StressProfile.java -- diff --git a/tools/stress/src/org/apache/cassandra/stress/StressProfile.java b/tools/stress/src/org/apache/cassandra/stress/StressProfile.java index 1964c27..3a20215 100644 --- a/tools/stress/src/org/apache/cassandra/stress/StressProfile.java +++ b/tools/stress/src/org/apache/cassandra/stress/StressProfile.java @@ -52,6 +52,7 @@ import org.apache.cassandra.stress.operations.userdefined.SchemaQuery; import org.apache.cassandra.stress.operations.userdefined.ValidatingSchemaQuery; import
[jira] [Commented] (CASSANDRA-12280) nodetool repair hangs
[ https://issues.apache.org/jira/browse/CASSANDRA-12280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411924#comment-15411924 ] Paulo Motta commented on CASSANDRA-12280: - bq. Are there any tools to dig deeper? More detailed logging? A way to get a trace of the repair thread? I mean there are not so many ways to "hang" either the thread is waiting for IO or it is locked. It should be quite easy to find out whats going on when seeing the BT. Perhaps try extracting a thread dump with {{jstack > dump.log}} ? > nodetool repair hangs > - > > Key: CASSANDRA-12280 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12280 > Project: Cassandra > Issue Type: Bug >Reporter: Benjamin Roth > > nodetool repair hangs when repairing a keyspace, does not hang when > repairting table/mv by table/mv. > Command executed (both variants make it hang): > nodetool repair likes like dislike_by_source_mv like_by_contact_mv > match_valid_mv like_out dislike match match_by_contact_mv like_valid_mv > like_out_by_source_mv > OR > nodetool repair likes > Logs: > https://gist.github.com/brstgt/bf8b20fa1942d29ab60926ede7340b75 > Nodetool output: > https://gist.github.com/brstgt/3aa73662da4b0190630ac1aad6c90a6f > Schema: > https://gist.github.com/brstgt/3fd59e0166f86f8065085532e3638097 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12393) dtest failure in bootstrap_test.TestBootstrap.local_quorum_bootstrap_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson reassigned CASSANDRA-12393: --- Assignee: Philip Thompson (was: Sean McCarthy) > dtest failure in bootstrap_test.TestBootstrap.local_quorum_bootstrap_test > - > > Key: CASSANDRA-12393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12393 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: Philip Thompson > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.2_dtest/666/testReport/bootstrap_test/TestBootstrap/local_quorum_bootstrap_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12167) Review JMX metrics test coverage
[ https://issues.apache.org/jira/browse/CASSANDRA-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411911#comment-15411911 ] Philip Thompson commented on CASSANDRA-12167: - This was discussed, and we established it would be best for a dev to do this, somewhere far down the line, yeah? > Review JMX metrics test coverage > > > Key: CASSANDRA-12167 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12167 > Project: Cassandra > Issue Type: Test >Reporter: Jim Witschey >Assignee: DS Test Eng > Labels: dtest > > I just deleted the dtest that was meant to smoke test JMX metrics: > https://github.com/riptano/cassandra-dtest/pull/1085 > The idea was that you'd read JMX metrics, run stress, then make sure the > metrics went up, down, or stayed the same, as appropriate. This kind of > coverage would be good to have. > I don't think we have it anywhere in the dtests, and it probably isn't > appropriate in unit tests. We should check there's no coverage in the unit > tests, and add some coverage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12167) Review JMX metrics test coverage
[ https://issues.apache.org/jira/browse/CASSANDRA-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12167: Issue Type: Test (was: Bug) > Review JMX metrics test coverage > > > Key: CASSANDRA-12167 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12167 > Project: Cassandra > Issue Type: Test >Reporter: Jim Witschey >Assignee: DS Test Eng > Labels: dtest > > I just deleted the dtest that was meant to smoke test JMX metrics: > https://github.com/riptano/cassandra-dtest/pull/1085 > The idea was that you'd read JMX metrics, run stress, then make sure the > metrics went up, down, or stayed the same, as appropriate. This kind of > coverage would be good to have. > I don't think we have it anywhere in the dtests, and it probably isn't > appropriate in unit tests. We should check there's no coverage in the unit > tests, and add some coverage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12407) dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test
Sean McCarthy created CASSANDRA-12407: - Summary: dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test Key: CASSANDRA-12407 URL: https://issues.apache.org/jira/browse/CASSANDRA-12407 Project: Cassandra Issue Type: Test Reporter: Sean McCarthy Assignee: Philip Thompson Attachments: node1.log, node2.log, node3.log example failure: http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/381/testReport/cql_tracing_test/TestCqlTracing/tracing_simple_test {code} Stacktrace File "/usr/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 102, in tracing_simple_test self.trace(session) File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 74, in trace self.assertIn('/127.0.0.1', out) File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn self.fail(self._formatMessage(msg, standardMsg)) File "/usr/lib/python2.7/unittest/case.py", line 410, in fail raise self.failureException(msg) '\'/127.0.0.1\' not found in "Consistency level set to ALL. {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CASSANDRA-12393) dtest failure in bootstrap_test.TestBootstrap.local_quorum_bootstrap_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean McCarthy updated CASSANDRA-12393: -- Comment: was deleted (was: This error was flushed out by cstar-97. I'm working on it over here: https://datastax.jira.com/browse/CSTAR-648) > dtest failure in bootstrap_test.TestBootstrap.local_quorum_bootstrap_test > - > > Key: CASSANDRA-12393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12393 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: Sean McCarthy > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log > > > example failure: > http://cassci.datastax.com/job/cassandra-2.2_dtest/666/testReport/bootstrap_test/TestBootstrap/local_quorum_bootstrap_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10848) Upgrade paging dtests involving deletion flap on CassCI
[ https://issues.apache.org/jira/browse/CASSANDRA-10848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-10848: Assignee: Russ Hatch (was: DS Test Eng) > Upgrade paging dtests involving deletion flap on CassCI > --- > > Key: CASSANDRA-10848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10848 > Project: Cassandra > Issue Type: Bug >Reporter: Jim Witschey >Assignee: Russ Hatch > Labels: dtest > Fix For: 3.0.x, 3.x > > > A number of dtests in the {{upgrade_tests.paging_tests}} that involve > deletion flap with the following error: > {code} > Requested pages were not delivered before timeout. > {code} > This may just be an effect of CASSANDRA-10730, but it's worth having a look > at separately. Here are some examples of tests flapping in this way: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12406) dtest failure in pushed_notifications_test.TestPushedNotifications.move_single_node_test
Sean McCarthy created CASSANDRA-12406: - Summary: dtest failure in pushed_notifications_test.TestPushedNotifications.move_single_node_test Key: CASSANDRA-12406 URL: https://issues.apache.org/jira/browse/CASSANDRA-12406 Project: Cassandra Issue Type: Test Reporter: Sean McCarthy Assignee: DS Test Eng Attachments: node1.log, node2.log, node3.log example failure: http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/271/testReport/pushed_notifications_test/TestPushedNotifications/move_single_node_test {code} Stacktrace File "/usr/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/home/automaton/cassandra-dtest/pushed_notifications_test.py", line 110, in move_single_node_test self.assertEquals(1, len(notifications), notifications) File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual assertion_func(first, second, msg=msg) File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual raise self.failureException(msg) "[{'change_type': u'MOVED_NODE', 'address': ('127.0.0.1', 9042)}, {'change_type': u'NEW_NODE', 'address': ('127.0.0.1', 9042)}] {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12402) Cassandra 3.7 unable to connect to any server CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-12402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta resolved CASSANDRA-12402. - Resolution: Duplicate > Cassandra 3.7 unable to connect to any server CQLSH > --- > > Key: CASSANDRA-12402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12402 > Project: Cassandra > Issue Type: Bug > Components: CQL > Environment: Ubuntu Server 16.04 LTS with apache cassandra 3.7 >Reporter: Steven Balderrama > Labels: newbie > Fix For: 3.7 > > > Apache cassandra version 3.7 is running on Ubuntu server 16.04 fine, all > parts of apache cassandra started up no problem, the issue is, i go to > connect using cqlsh: > $ CQLSH (My IP Address) 9160 > then it says: > Connection error: ('Unable to connect to any servers', {'10.0.0.13': > TypeError('ref() does not take keyword arguments',)}) > i seen there was a bug for it: > https://issues.apache.org/jira/browse/CASSANDRA-11850 > but its for version cqlsh --version: cqlsh 5.0.1 > cassandra -v: 3.5 (also occurs with 3.0.6) > is it still happening for version 3.7 still?? i see there is a fix, how do i > get it? the links are broken, also how do I apply it?? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12402) Cassandra 3.7 unable to connect to any server CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-12402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411876#comment-15411876 ] Paulo Motta commented on CASSANDRA-12402: - As you already mentioned, this was fixed in CASSANDRA-11850 (unreleased 3.0.9 or 3.9), so you should not open another ticket for it. You have a few options: * Use the workaround described in the ticket: {noformat} If you have an up-to-date cassandra-driver installed, you can disable the embedded driver by setting the environment variable CQLSH_NO_BUNDLED to any non empty string, for example export CQLSH_NO_BUNDLED=true. {noformat} * Clone cassandra source code in your version and apply/cherry-pick one of the patches available there for a pre-release fix * Wait for the release of 3.9 or 3.09 and upgrade If you have questions regarding this process you can reach out to other developers on #cassandra, #cassandra-dev (on irc.freenode.net) or [mailing lists|https://cassandra.apache.org/community/] since JIRA is not a support forum. > Cassandra 3.7 unable to connect to any server CQLSH > --- > > Key: CASSANDRA-12402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12402 > Project: Cassandra > Issue Type: Bug > Components: CQL > Environment: Ubuntu Server 16.04 LTS with apache cassandra 3.7 >Reporter: Steven Balderrama > Labels: newbie > Fix For: 3.7 > > > Apache cassandra version 3.7 is running on Ubuntu server 16.04 fine, all > parts of apache cassandra started up no problem, the issue is, i go to > connect using cqlsh: > $ CQLSH (My IP Address) 9160 > then it says: > Connection error: ('Unable to connect to any servers', {'10.0.0.13': > TypeError('ref() does not take keyword arguments',)}) > i seen there was a bug for it: > https://issues.apache.org/jira/browse/CASSANDRA-11850 > but its for version cqlsh --version: cqlsh 5.0.1 > cassandra -v: 3.5 (also occurs with 3.0.6) > is it still happening for version 3.7 still?? i see there is a fix, how do i > get it? the links are broken, also how do I apply it?? -- This message was sent by Atlassian JIRA (v6.3.4#6332)