cassandra git commit: remove dead parm 'isDense', obsoleted by 9c3855b

[dbrosius]

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
 {
 

[jira] [Commented] (CASSANDRA-11990) Address rows rather than partitions in SASI

[Pavel Yaskevich (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Pavel Yaskevich (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Stefania (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Stefania (JIRA)]

 [ 
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

[Stefania (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Kaide Mu (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Geoffrey Yu (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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 (JIRA)]

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

[Ariel Weisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[Joshua McKenzie (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Daniel Cohen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[Robert Stupp (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Brad Vernon (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Russ Hatch (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Russ Hatch (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Russ Hatch (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Benjamin Lerer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Joel Knighton (JIRA)]

 [ 
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

[Alex Petrov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Sean McCarthy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[Joshua McKenzie (JIRA)]

 [ 
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

[Russ Hatch (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Aleksey Yeschenko (JIRA)]

 [ 
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

[Aleksey Yeschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[aleksey]

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

[aleksey]

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)

[aleksey]

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

[Aleksey Yeschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[aleksey]

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

[aleksey]

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

[aleksey]

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

--

--

[2/3] cassandra git commit: Fix encoding of cell names for super columns (CASSANDRA-12235 follow-up)

[aleksey]

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);
 }

[3/3] cassandra git commit: Merge branch 'cassandra-3.9' into trunk

[aleksey]

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(-)
--

[1/3] cassandra git commit: Fix encoding of cell names for super columns (CASSANDRA-12235 follow-up)

[aleksey]

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

[Robert Stupp (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

 [ 
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/
> 

[jira] [Created] (CASSANDRA-12411) Do not store passwords in .cassandra/cqlsh_history

[jonathan lacefield (JIRA)]

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.

[Joshua McKenzie (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Paulo Motta (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Jeremiah Jordan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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_in_kb 
> instead

[jira] [Comment Edited] (CASSANDRA-12246) Cassandra v2.2 to v3.0.9 upgrade failed

[Jeremiah Jordan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 requested but 

[jira] [Commented] (CASSANDRA-12167) Review JMX metrics test coverage

[Philip Thompson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[Jim Witschey (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[Sean McCarthy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Sean McCarthy (JIRA)]

 [ 
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 (JIRA)]

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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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 (JIRA)]

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

[Ariel Weisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

 [ 
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 (JIRA)]

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

[T Jake Luciani (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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

[jake]

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 

[jira] [Commented] (CASSANDRA-12280) nodetool repair hangs

[Paulo Motta (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Philip Thompson (JIRA)]

 [ 
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 (JIRA)]

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

[Sean McCarthy (JIRA)]

 [ 
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

[Philip Thompson (JIRA)]

 [ 
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 (JIRA)]

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

[Paulo Motta (JIRA)]

 [ 
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

[Paulo Motta (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Updated] (CASSANDRA-11906) Unstable JVM due too many files when anticompacting big LCS tables

[Philip Thompson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Philip Thompson updated CASSANDRA-11906:

Fix Version/s: 3.0.x

> Unstable JVM due too many files when anticompacting big LCS tables
> --
>
> Key: CASSANDRA-11906
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11906
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefano Ortolani
>Assignee: DS Test Eng
> Fix For: 3.0.x
>
>
> I have recently moved from C* 2.1.x to C* 3.0.6. The setup is quite 
> heavy:
>   - 13 nodes with spinning disks
>   - ~120 GB of data per node
>   - 50% of CFs are LCS and have quite wide rows.
>   - 2/3 CFs with LCS have more than 200 SStables
> Incremental repairs do not seem to play really well with that.
> I have been running some tests node by node by using the -pr option:
> {code:xml}
> nodetool -h localhost repair -pr keyscheme
> {code}
> and to my surprise the whole process takes quite some time (1 hour
> minimum, 8 hours if I haven't been repairing for 5/6 days).
> Yesterday I tried to run the command with the -seq option so to 
> decrease the number of simultanoues compactions. After a while
> the node on which I was running the repair simply died during
> the anticompaction phase with the following
> exception in the logs.
> {code:xml}
> ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-25 21:54:21,868 
> ScheduledReporter.java:119 - RuntimeException thrown from 
> GraphiteReporter#report. Exception was suppressed.
> java.lang.RuntimeException: Failed to list files in 
> /data/cassandra/data/keyschema/columnfamily-3996ce80b7ac11e48a9b6776bf484396
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:57)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:547)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.filter(Directories.java:691)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.listFiles(Directories.java:662)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$TrueFilesSizeVisitor.(Directories.java:981)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.getTrueAllocatedSizeIn(Directories.java:893)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.trueSnapshotsSize(Directories.java:883) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.trueSnapshotsSize(ColumnFamilyStore.java:2332)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:637) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:634) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> com.codahale.metrics.graphite.GraphiteReporter.reportGauge(GraphiteReporter.java:281)
>  ~[metrics-graphite-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:158)
>  ~[metrics-graphite-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162) 
> ~[metrics-core-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117) 
> ~[metrics-core-3.1.0.jar:3.1.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_91]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_91]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_91]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> Caused by: java.lang.RuntimeException: java.nio.file.FileSystemException: 
> /data/cassandra/data/keyschema/columnfamily-3996ce80b7ac11e48a9b6776bf484396/ma_txn_anticompactionafterrepair_f20b50d0-22bd-11e6-970f-6f22464f4624.log:
>  Too many open files
>   at org.apache.cassandra.io.util.FileUtils.readLines(FileUtils.java:622) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1321) 
> ~[na:1.8.0_91]
>   at 

[jira] [Updated] (CASSANDRA-12124) dtest failure in upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_next_2_1_x_To_head_trunk.select_with_alias_test

[Philip Thompson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Philip Thompson updated CASSANDRA-12124:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_next_2_1_x_To_head_trunk.select_with_alias_test
> -
>
> Key: CASSANDRA-12124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12124
> Project: Cassandra
>  Issue Type: Test
>Reporter: Philip Thompson
>Assignee: Sylvain Lebresne
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/upgrade_tests-all-custom_branch_runs/37/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_next_2_1_x_To_head_trunk/select_with_alias_test
> Failed on CassCI build upgrade_tests-all-custom_branch_runs #37
> This is just a problem with different error messages across C* versions. 
> Someone needs to do the legwork of figuring out what is required where, and 
> filtering. The query is failing correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11960) Hints are not seekable

[Aleksey Yeschenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-11960:
--
   Resolution: Fixed
Fix Version/s: 3.10
   Status: Resolved  (was: Ready to Commit)

> Hints are not seekable
> --
>
> Key: CASSANDRA-11960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11960
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Stefan Podkowinski
> Fix For: 3.10
>
> Attachments: 11960-trunk.patch
>
>
> Got the following error message on trunk. No idea how to reproduce. But the 
> only thing the (not overridden) seek method does is throwing this exception.
> {code}
> ERROR [HintsDispatcher:2] 2016-06-05 18:51:09,397 CassandraDaemon.java:222 - 
> Exception in thread Thread[HintsDispatcher:2,1,main]
> java.lang.UnsupportedOperationException: Hints are not seekable.
>   at org.apache.cassandra.hints.HintsReader.seek(HintsReader.java:114) 
> ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.seek(HintsDispatcher.java:79) 
> ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:257)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:220)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:199)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_91]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_91]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11960) Hints are not seekable

[Aleksey Yeschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15411770#comment-15411770
 ] 

Aleksey Yeschenko commented on CASSANDRA-11960:
---

Committed as 
[cee22ad54d7c28aaf0868dd45aeb9b5b708b0e78|https://github.com/apache/cassandra/commit/cee22ad54d7c28aaf0868dd45aeb9b5b708b0e78]
 to trunk, thanks.

> Hints are not seekable
> --
>
> Key: CASSANDRA-11960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11960
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Stefan Podkowinski
> Fix For: 3.10
>
> Attachments: 11960-trunk.patch
>
>
> Got the following error message on trunk. No idea how to reproduce. But the 
> only thing the (not overridden) seek method does is throwing this exception.
> {code}
> ERROR [HintsDispatcher:2] 2016-06-05 18:51:09,397 CassandraDaemon.java:222 - 
> Exception in thread Thread[HintsDispatcher:2,1,main]
> java.lang.UnsupportedOperationException: Hints are not seekable.
>   at org.apache.cassandra.hints.HintsReader.seek(HintsReader.java:114) 
> ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.seek(HintsDispatcher.java:79) 
> ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:257)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:220)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:199)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_91]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_91]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)