[jira] [Updated] (CASSANDRA-11850) cannot use cql since upgrading python to 2.7.11+

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-11850:
-
Fix Version/s: 2.2.x

> cannot use cql since upgrading python to 2.7.11+
> 
>
> Key: CASSANDRA-11850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11850
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Development
>Reporter: Andrew Madison
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> OS: Debian GNU/Linux stretch/sid 
> Kernel: 4.5.0-2-amd64 #1 SMP Debian 4.5.4-1 (2016-05-16) x86_64 GNU/Linux
> Python version: 2.7.11+ (default, May  9 2016, 15:54:33)
> [GCC 5.3.1 20160429]
> cqlsh --version: cqlsh 5.0.1
> cassandra -v: 3.5 (also occurs with 3.0.6)
> Issue:
> when running cqlsh, it returns the following error:
> cqlsh -u dbarpt_usr01
> Password: *
> Connection error: ('Unable to connect to any servers', {'odbasandbox1': 
> TypeError('ref() does not take keyword arguments',)})
> I cleared PYTHONPATH:
> python -c "import json; print dir(json); print json.__version__"
> ['JSONDecoder', 'JSONEncoder', '__all__', '__author__', '__builtins__', 
> '__doc__', '__file__', '__name__', '__package__', '__path__', '__version__', 
> '_default_decoder', '_default_encoder', 'decoder', 'dump', 'dumps', 
> 'encoder', 'load', 'loads', 'scanner']
> 2.0.9
> Java based clients can connect to Cassandra with no issue. Just CQLSH and 
> Python clients cannot.
> nodetool status also works.
> Thank you for your help.



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

[jira] [Commented] (CASSANDRA-11740) Nodes have wrong membership view of the cluster

[Dikang Gu (JIRA)]

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

Dikang Gu commented on CASSANDRA-11740:
---

[~jkni], any ideas why this would happen?  In what case, one node can not get 
the DC/Rack information about other nodes?

> Nodes have wrong membership view of the cluster
> ---
>
> Key: CASSANDRA-11740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11740
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Joel Knighton
> Fix For: 2.2.x, 3.x
>
>
> We have a few hundreds nodes across 3 data centers, and we are doing a few 
> millions writes per second into the cluster.
> The problem we found is that there are some nodes (>10) have very wrong view 
> of the cluster.
> For example, we have 3 data centers A, B and C. On the problem nodes, in the 
> output of the 'nodetool status', it shows that ~100 nodes are not in data 
> center A, B, or C. Instead, it shows nodes are in DC1, and rack r1, which is 
> very wrong. And as a result, the node will return wrong results to client 
> requests.
> {code}
> Datacenter: DC1
> ===
> Status=Up/Down
> / State=Normal/Leaving/Joining/Moving
> – Address Load Tokens Owns Host ID Rack
> UN 2401:db00:11:6134:face:0:1:0 509.52 GB 256 ? 
> e24656ac-c3b2-4117-b933-a5b06852c993 r1
> UN 2401:db00:11:b218:face:0:5:0 510.01 GB 256 ? 
> 53da2104-b1b5-4fa5-a3dd-52c7557149f9 r1
> UN 2401:db00:2130:5133:face:0:4d:0 459.75 GB 256 ? 
> ef8311f0-f6b8-491c-904d-baa925cdd7c2 r1
> {code}
> We are using GossipingPropertyFileSnitch.
> Thanks



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

[jira] [Commented] (CASSANDRA-12127) Queries with empty ByteBuffer values in clustering column restrictions fail for non-composite compact tables

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-12127:
-

Great find & investigation! 

The behaviour of {{2.1}} / {{2.2}} can be explained by (leaving the class cast 
aside) the fact that there's no distinction between not specifying the 
clustering slice at all and specifying the empty buffer (therefore in both 
cases 2 rows are returned). Empty buffer would get translated to 
{{Composites#EMPTY}} and afterwards get discarded by 
{{AtomicBTreeColumns#slice}} as it checks for {{isEmpty}} and replaces all 
empty bounds with {{null}}. 

Semantically, {{>}} with empty byte buffer would be same as specifying no 
condition at all, and in case with {{<}} (same as {{=}}) result is more or less 
known in advance: no results.

> Queries with empty ByteBuffer values in clustering column restrictions fail 
> for non-composite compact tables
> 
>
> Key: CASSANDRA-12127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12127
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> For the following table:
> {code}
> CREATE TABLE myTable (pk int,
>   c blob,
>   value int,
>   PRIMARY KEY (pk, c)) WITH COMPACT STORAGE;
> INSERT INTO myTable (pk, c, value) VALUES (1, textAsBlob('1'), 1);
> INSERT INTO myTable (pk, c, value) VALUES (1, textAsBlob('2'), 2);
> {code}
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c > textAsBlob('');}}
> Will result in the following Exception:
> {code}
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.Composites$EmptyComposite cannot be cast 
> to org.apache.cassandra.db.composites.CellName
>   at 
> org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
>   at 
> org.apache.cassandra.db.composites.AbstractSimpleCellNameType.makeCellName(AbstractSimpleCellNameType.java:125)
>   at 
> org.apache.cassandra.db.composites.AbstractCellNameType.makeCellName(AbstractCellNameType.java:254)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeExclusiveSliceBound(SelectStatement.java:1206)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.applySliceRestriction(SelectStatement.java:1214)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1292)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1259)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:299)
>   [...]
> {code}
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c < textAsBlob('');}}
> Will return 2 rows instead of 0.
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c = textAsBlob('');}}
> {code}
> java.lang.AssertionError
>   at 
> org.apache.cassandra.db.composites.SimpleDenseCellNameType.create(SimpleDenseCellNameType.java:60)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.addSelectedColumns(SelectStatement.java:853)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getRequestedColumns(SelectStatement.java:846)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeFilter(SelectStatement.java:583)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:383)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:253)
>   [...]
> {code}
> I checked 2.0 and {{SELECT * FROM myTable  WHERE pk = 1 AND c > 
> textAsBlob('');}} works properly but {{SELECT * FROM myTable WHERE pk = 1 AND 
> c < textAsBlob('');}} return the same wrong results than in 2.1.
> The {{SELECT * FROM myTable WHERE pk = 1 AND c = textAsBlob('');}} is 
> rejected if a clear error message: {{Invalid empty value for clustering 
> column of COMPACT TABLE}}.
> As it is not possible to insert an empty ByteBuffer value within the 
> clustering column of a non-composite compact tables those queries do not
> have a lot of meaning. {{SELECT * FROM myTable WHERE pk = 1 AND c < 
> textAsBlob('');}} and {{SELECT * FROM myTable WHERE pk = 1 AND c = 
> textAsBlob('');}} will return nothing
> and {{SELECT * FROM myTable WHERE pk = 1 AND c > textAsBlob('');}} will 
> return the entire partition (pk = 1).
> In my opinion those queries should probably all be rejected as it seems that 
> the fact that {{SELECT * FROM myTable  WHERE pk = 1 AND c > textAsBlob('');}} 
> was accepted in {{2.0}} was due to a bug.
> I am of course open to discussion.



--
This message was sent by 

[jira] [Commented] (CASSANDRA-12072) dtest failure in auth_test.TestAuthRoles.udf_permissions_in_selection_test

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-12072:
---

It's looking likely that this is a consequence of a netty issue we've reported 
upstream at [netty #5486|https://github.com/netty/netty/issues/5486]. This 
issue was introduced with netty 4.0.37; going back to netty 4.0.36, I can no 
longer reproduce the failures.

I'll update when we know more.

> dtest failure in auth_test.TestAuthRoles.udf_permissions_in_selection_test
> --
>
> Key: CASSANDRA-12072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12072
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Joel Knighton
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log
>
>
> Multiple failures:
> http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/auth_test/TestAuthRoles/udf_permissions_in_selection_test
> http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/auth_test/TestAuthRoles/create_and_grant_roles_with_superuser_status_test/
> http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/auth_test/TestAuthRoles/drop_keyspace_cleans_up_function_level_permissions_test/
> http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_reading_max_parse_errors/
> http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_read_wrong_column_names/
> http://cassci.datastax.com/job/trunk_offheap_dtest/264/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_boolstyle_round_trip/
> http://cassci.datastax.com/job/trunk_offheap_dtest/264/testReport/compaction_test/TestCompaction_with_SizeTieredCompactionStrategy/disable_autocompaction_alter_test/
> http://cassci.datastax.com/job/trunk_offheap_dtest/264/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe/
> http://cassci.datastax.com/job/trunk_offheap_dtest/264/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe_mv/
> Logs are from 
> http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/auth_test/TestAuthRoles/udf_permissions_in_selection_test/



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

[jira] [Comment Edited] (CASSANDRA-12127) Queries with empty ByteBuffer values in clustering column restrictions fail for non-composite compact tables

[Jason Brown (JIRA)]

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

Jason Brown edited comment on CASSANDRA-12127 at 7/1/16 9:03 PM:
-

In the interest in completeness, I've taken [~blerer] 's sample queries (the 
difference being >, <, or = operators before {{textAsBlob()}}), and discovered 
the following:

||op||2.0||2.1/2.2||3.0/trunk||
| {{>}} | return 2 rows | ClassCastException | return 2 rows |
| {{<}} | return 2 rows | ClassCastException | return 0 rows |
| {{=}} | "Invalid empty value for clustering column of COMPACT TABLE" | 
AssertionError | return 0 rows |

As this behavior (passing an empty buffer to {{textAsBlob()}}) is allowable and 
correct as of 3.0 and trunk, I propose we fix this for 2.1 and 2.2 (I suspect 
it's the same fix, though I'm not very familiar with this part of the code 
base). I agree with [~blerer] that the behavior in 2.0 was certainly buggy, but 
the fact that it's working correctly in 3.0 and up indicates we should fix it 
for the intervening versions.

UPDATE: we should fix it to behave like 3.0/trunk, not 2.0 ;)




was (Author: jasobrown):
In the interest in completeness, I've taken [~blerer] 's sample queries (the 
difference being >, <, or = operators before {{textAsBlob()}}), and discovered 
the following:

||op||2.0||2.1/2.2||3.0/trunk||
| {{>}} | return all partition rows | ClassCastException | return 2 rows |
| {{<}} | return all partition rows | ClassCastException | return 0 rows |
| {{=}} | "Invalid empty value for clustering column of COMPACT TABLE" | 
AssertionError | return 0 rows |

As this behavior (passing an empty buffer to {{textAsBlob()}}) is allowable and 
correct as of 3.0 and trunk, I propose we fix this for 2.1 and 2.2 (I suspect 
it's the same fix, though I'm not very familiar with this part of the code 
base). I agree with [~blerer] that the behavior in 2.0 was certainly buggy, but 
the fact that it's working correctly in 3.0 and up indicates we should fix it 
for the intervening versions.

UPDATE: we should fix it to behave like 3.0/trunk, not 2.0 ;)



> Queries with empty ByteBuffer values in clustering column restrictions fail 
> for non-composite compact tables
> 
>
> Key: CASSANDRA-12127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12127
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> For the following table:
> {code}
> CREATE TABLE myTable (pk int,
>   c blob,
>   value int,
>   PRIMARY KEY (pk, c)) WITH COMPACT STORAGE;
> INSERT INTO myTable (pk, c, value) VALUES (1, textAsBlob('1'), 1);
> INSERT INTO myTable (pk, c, value) VALUES (1, textAsBlob('2'), 2);
> {code}
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c > textAsBlob('');}}
> Will result in the following Exception:
> {code}
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.Composites$EmptyComposite cannot be cast 
> to org.apache.cassandra.db.composites.CellName
>   at 
> org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
>   at 
> org.apache.cassandra.db.composites.AbstractSimpleCellNameType.makeCellName(AbstractSimpleCellNameType.java:125)
>   at 
> org.apache.cassandra.db.composites.AbstractCellNameType.makeCellName(AbstractCellNameType.java:254)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeExclusiveSliceBound(SelectStatement.java:1206)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.applySliceRestriction(SelectStatement.java:1214)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1292)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1259)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:299)
>   [...]
> {code}
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c < textAsBlob('');}}
> Will return 2 rows instead of 0.
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c = textAsBlob('');}}
> {code}
> java.lang.AssertionError
>   at 
> org.apache.cassandra.db.composites.SimpleDenseCellNameType.create(SimpleDenseCellNameType.java:60)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.addSelectedColumns(SelectStatement.java:853)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getRequestedColumns(SelectStatement.java:846)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeFilter(SelectStatement.java:583)
>   at 
> 

[jira] [Comment Edited] (CASSANDRA-12127) Queries with empty ByteBuffer values in clustering column restrictions fail for non-composite compact tables

[Jason Brown (JIRA)]

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

Jason Brown edited comment on CASSANDRA-12127 at 7/1/16 8:41 PM:
-

In the interest in completeness, I've taken [~blerer] 's sample queries (the 
difference being >, <, or = operators before {{textAsBlob()}}), and discovered 
the following:

||op||2.0||2.1/2.2||3.0/trunk||
| {{>}} | return all partition rows | ClassCastException | return 2 rows |
| {{<}} | return all partition rows | ClassCastException | return 0 rows |
| {{=}} | "Invalid empty value for clustering column of COMPACT TABLE" | 
AssertionError | return 0 rows |

As this behavior (passing an empty buffer to {{textAsBlob()}}) is allowable and 
correct as of 3.0 and trunk, I propose we fix this for 2.1 and 2.2 (I suspect 
it's the same fix, though I'm not very familiar with this part of the code 
base). I agree with [~blerer] that the behavior in 2.0 was certainly buggy, but 
the fact that it's working correctly in 3.0 and up indicates we should fix it 
for the intervening versions.

UPDATE: we should fix it to behave like 3.0/trunk, not 2.0 ;)




was (Author: jasobrown):
In the interest in completeness, I've taken [~blerer] 's sample queries (the 
difference being >, <, or = operators before {{textAsBlob()}}), and discovered 
the following:

||op||2.0||2.1/2.2||3.0/trunk||
| {{>}} | return all partition rows | ClassCastException | return 2 rows |
| {{<}} | return all partition rows | ClassCastException | return 0 rows |
| {{=}} | "Invalid empty value for clustering column of COMPACT TABLE" | 
AssertionError | return 0 rows |

As this behavior (passing an empty buffer to {{textAsBlob()}}) is allowable and 
correct as of 3.0 and trunk, I propose we fix this for 2.1 and 2.2 (I suspect 
it's the same fix, though I'm not very familiar with this part of the code 
base). I agree with [~blerer] that the behavior in 2.0 was certainly buggy, but 
the fact that it's working correctly in 3.0 and up indicates we should fix it 
for the intervening versions.



> Queries with empty ByteBuffer values in clustering column restrictions fail 
> for non-composite compact tables
> 
>
> Key: CASSANDRA-12127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12127
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> For the following table:
> {code}
> CREATE TABLE myTable (pk int,
>   c blob,
>   value int,
>   PRIMARY KEY (pk, c)) WITH COMPACT STORAGE;
> INSERT INTO myTable (pk, c, value) VALUES (1, textAsBlob('1'), 1);
> INSERT INTO myTable (pk, c, value) VALUES (1, textAsBlob('2'), 2);
> {code}
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c > textAsBlob('');}}
> Will result in the following Exception:
> {code}
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.Composites$EmptyComposite cannot be cast 
> to org.apache.cassandra.db.composites.CellName
>   at 
> org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
>   at 
> org.apache.cassandra.db.composites.AbstractSimpleCellNameType.makeCellName(AbstractSimpleCellNameType.java:125)
>   at 
> org.apache.cassandra.db.composites.AbstractCellNameType.makeCellName(AbstractCellNameType.java:254)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeExclusiveSliceBound(SelectStatement.java:1206)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.applySliceRestriction(SelectStatement.java:1214)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1292)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1259)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:299)
>   [...]
> {code}
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c < textAsBlob('');}}
> Will return 2 rows instead of 0.
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c = textAsBlob('');}}
> {code}
> java.lang.AssertionError
>   at 
> org.apache.cassandra.db.composites.SimpleDenseCellNameType.create(SimpleDenseCellNameType.java:60)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.addSelectedColumns(SelectStatement.java:853)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getRequestedColumns(SelectStatement.java:846)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeFilter(SelectStatement.java:583)
>   at 
> 

[jira] [Commented] (CASSANDRA-12127) Queries with empty ByteBuffer values in clustering column restrictions fail for non-composite compact tables

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-12127:
-

In the interest in completeness, I've taken [~blerer] 's sample queries (the 
difference being >, <, or = operators before {{textAsBlob()}}), and discovered 
the following:

||op||2.0||2.1/2.2||3.0/trunk||
| {{>}} | return all partition rows | ClassCastException | return 2 rows |
| {{<}} | return all partition rows | ClassCastException | return 0 rows |
| {{=}} | "Invalid empty value for clustering column of COMPACT TABLE" | 
AssertionError | return 0 rows |

As this behavior (passing an empty buffer to {{textAsBlob()}}) is allowable and 
correct as of 3.0 and trunk, I propose we fix this for 2.1 and 2.2 (I suspect 
it's the same fix, though I'm not very familiar with this part of the code 
base). I agree with [~blerer] that the behavior in 2.0 was certainly buggy, but 
the fact that it's working correctly in 3.0 and up indicates we should fix it 
for the intervening versions.



> Queries with empty ByteBuffer values in clustering column restrictions fail 
> for non-composite compact tables
> 
>
> Key: CASSANDRA-12127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12127
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> For the following table:
> {code}
> CREATE TABLE myTable (pk int,
>   c blob,
>   value int,
>   PRIMARY KEY (pk, c)) WITH COMPACT STORAGE;
> INSERT INTO myTable (pk, c, value) VALUES (1, textAsBlob('1'), 1);
> INSERT INTO myTable (pk, c, value) VALUES (1, textAsBlob('2'), 2);
> {code}
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c > textAsBlob('');}}
> Will result in the following Exception:
> {code}
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.Composites$EmptyComposite cannot be cast 
> to org.apache.cassandra.db.composites.CellName
>   at 
> org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
>   at 
> org.apache.cassandra.db.composites.AbstractSimpleCellNameType.makeCellName(AbstractSimpleCellNameType.java:125)
>   at 
> org.apache.cassandra.db.composites.AbstractCellNameType.makeCellName(AbstractCellNameType.java:254)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeExclusiveSliceBound(SelectStatement.java:1206)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.applySliceRestriction(SelectStatement.java:1214)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1292)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1259)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:299)
>   [...]
> {code}
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c < textAsBlob('');}}
> Will return 2 rows instead of 0.
> The query: {{SELECT * FROM myTable WHERE pk = 1 AND c = textAsBlob('');}}
> {code}
> java.lang.AssertionError
>   at 
> org.apache.cassandra.db.composites.SimpleDenseCellNameType.create(SimpleDenseCellNameType.java:60)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.addSelectedColumns(SelectStatement.java:853)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getRequestedColumns(SelectStatement.java:846)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeFilter(SelectStatement.java:583)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:383)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:253)
>   [...]
> {code}
> I checked 2.0 and {{SELECT * FROM myTable  WHERE pk = 1 AND c > 
> textAsBlob('');}} works properly but {{SELECT * FROM myTable WHERE pk = 1 AND 
> c < textAsBlob('');}} return the same wrong results than in 2.1.
> The {{SELECT * FROM myTable WHERE pk = 1 AND c = textAsBlob('');}} is 
> rejected if a clear error message: {{Invalid empty value for clustering 
> column of COMPACT TABLE}}.
> As it is not possible to insert an empty ByteBuffer value within the 
> clustering column of a non-composite compact tables those queries do not
> have a lot of meaning. {{SELECT * FROM myTable WHERE pk = 1 AND c < 
> textAsBlob('');}} and {{SELECT * FROM myTable WHERE pk = 1 AND c = 
> textAsBlob('');}} will return nothing
> and {{SELECT * FROM myTable WHERE pk = 1 AND c > textAsBlob('');}} will 
> return the entire partition (pk = 1).
> In my opinion those queries should probably all be 

[2/5] cassandra git commit: update license txt file version numbers

[dbrosius]

update license txt file version numbers


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/da20fece
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/da20fece
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/da20fece

Branch: refs/heads/trunk
Commit: da20fece744ab37d7355daa75e1717c08c83e4de
Parents: 82cdc86
Author: Dave Brosius 
Authored: Fri Jul 1 16:08:35 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 16:08:35 2016 -0400

--
 lib/licenses/logback-classic-1.1.2.txt | 70 -
 lib/licenses/logback-classic-1.1.3.txt | 70 +
 lib/licenses/logback-core-1.1.2.txt| 70 -
 lib/licenses/logback-core-1.1.3.txt| 70 +
 4 files changed, 140 insertions(+), 140 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/da20fece/lib/licenses/logback-classic-1.1.2.txt
--
diff --git a/lib/licenses/logback-classic-1.1.2.txt 
b/lib/licenses/logback-classic-1.1.2.txt
deleted file mode 100644
index 79e486c..000
--- a/lib/licenses/logback-classic-1.1.2.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-Eclipse Public License - v 1.0
-
-THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE PUBLIC 
LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM 
CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.
-
-1. DEFINITIONS
-
-"Contribution" means:
-
-a) in the case of the initial Contributor, the initial code and documentation 
distributed under this Agreement, and
-b) in the case of each subsequent Contributor:
-i) changes to the Program, and
-ii) additions to the Program;
-where such changes and/or additions to the Program originate from and are 
distributed by that particular Contributor. A Contribution 'originates' from a 
Contributor if it was added to the Program by such Contributor itself or anyone 
acting on such Contributor's behalf. Contributions do not include additions to 
the Program which: (i) are separate modules of software distributed in 
conjunction with the Program under their own license agreement, and (ii) are 
not derivative works of the Program.
-"Contributor" means any person or entity that distributes the Program.
-
-"Licensed Patents" mean patent claims licensable by a Contributor which are 
necessarily infringed by the use or sale of its Contribution alone or when 
combined with the Program.
-
-"Program" means the Contributions distributed in accordance with this 
Agreement.
-
-"Recipient" means anyone who receives the Program under this Agreement, 
including all Contributors.
-
-2. GRANT OF RIGHTS
-
-a) Subject to the terms of this Agreement, each Contributor hereby grants 
Recipient a non-exclusive, worldwide, royalty-free copyright license to 
reproduce, prepare derivative works of, publicly display, publicly perform, 
distribute and sublicense the Contribution of such Contributor, if any, and 
such derivative works, in source code and object code form.
-b) Subject to the terms of this Agreement, each Contributor hereby grants 
Recipient a non-exclusive, worldwide, royalty-free patent license under 
Licensed Patents to make, use, sell, offer to sell, import and otherwise 
transfer the Contribution of such Contributor, if any, in source code and 
object code form. This patent license shall apply to the combination of the 
Contribution and the Program if, at the time the Contribution is added by the 
Contributor, such addition of the Contribution causes such combination to be 
covered by the Licensed Patents. The patent license shall not apply to any 
other combinations which include the Contribution. No hardware per se is 
licensed hereunder.
-c) Recipient understands that although each Contributor grants the licenses to 
its Contributions set forth herein, no assurances are provided by any 
Contributor that the Program does not infringe the patent or other intellectual 
property rights of any other entity. Each Contributor disclaims any liability 
to Recipient for claims brought by any other entity based on infringement of 
intellectual property rights or otherwise. As a condition to exercising the 
rights and licenses granted hereunder, each Recipient hereby assumes sole 
responsibility to secure any other intellectual property rights needed, if any. 
For example, if a third party patent license is required to allow Recipient to 
distribute the Program, it is Recipient's responsibility to acquire that 
license before distributing the Program.
-d) Each Contributor represents that to its knowledge it has sufficient 
copyright rights in its Contribution, if any, to grant the copyright 

[3/5] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[dbrosius]

Merge branch 'cassandra-2.1' into cassandra-2.2

Conflicts:
lib/licenses/crc32ex-0.1.1.txt
lib/licenses/snappy-java-1.0.5.2.txt
lib/licenses/snappy-java-1.0.5.txt
lib/licenses/snappy-java-1.1.1.7.txt
lib/licenses/thrift-server-0.3.5.txt
lib/licenses/thrift-server-0.3.7.txt


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/65f8bb6c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/65f8bb6c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/65f8bb6c

Branch: refs/heads/trunk
Commit: 65f8bb6c4635fee4e17b2023915701dce59bc3c8
Parents: da20fec bd6ad43
Author: Dave Brosius 
Authored: Fri Jul 1 16:10:55 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 16:10:55 2016 -0400

--

--

[5/5] cassandra git commit: Merge branch 'cassandra-3.0' into trunk

[dbrosius]

Merge branch 'cassandra-3.0' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f542a2ea
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f542a2ea
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f542a2ea

Branch: refs/heads/trunk
Commit: f542a2ea6e72e359e882be69d454f4e55680ad66
Parents: 1df47bd db61372
Author: Dave Brosius 
Authored: Fri Jul 1 16:16:08 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 16:16:08 2016 -0400

--

--

[1/5] cassandra git commit: update license file versions

[dbrosius]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 1df47bd76 -> f542a2ea6


update license file versions


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/bd6ad43b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/bd6ad43b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/bd6ad43b

Branch: refs/heads/trunk
Commit: bd6ad43b9cda883d5aa151fe8580de2f8784e85f
Parents: 40b18d5
Author: Dave Brosius 
Authored: Fri Jul 1 15:53:29 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 15:53:29 2016 -0400

--
 lib/licenses/snappy-java-1.0.5.2.txt | 209 ++
 lib/licenses/snappy-java-1.0.5.txt   | 209 --
 lib/licenses/thrift-server-0.3.5.txt | 202 -
 lib/licenses/thrift-server-0.3.7.txt | 202 +
 4 files changed, 411 insertions(+), 411 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bd6ad43b/lib/licenses/snappy-java-1.0.5.2.txt
--
diff --git a/lib/licenses/snappy-java-1.0.5.2.txt 
b/lib/licenses/snappy-java-1.0.5.2.txt
new file mode 100644
index 000..d5c4984
--- /dev/null
+++ b/lib/licenses/snappy-java-1.0.5.2.txt
@@ -0,0 +1,209 @@
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+  "License" shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  "Legal Entity" shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  "control" means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  "You" (or "Your") shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  "Source" form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  "Object" form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  "Work" shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  "Derivative Works" shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  "Contribution" shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, "submitted"
+  means any form of electronic, verbal, or written communication sent
+  to the Licensor or its representatives, including but not limited to
+  communication on electronic mailing lists, source code control systems,
+  and issue tracking systems that are managed by, or on behalf of, the
+  Licensor for the purpose of discussing and improving the Work, but
+  excluding communication that is conspicuously marked or otherwise
+  designated in writing by the copyright owner as "Not a Contribution."
+
+  "Contributor" shall mean Licensor and any individual or Legal Entity
+  on behalf 

[4/5] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[dbrosius]

Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/db613724
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/db613724
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/db613724

Branch: refs/heads/trunk
Commit: db6137249837c255a687db7636471e4f7a15f53b
Parents: 6b24109 65f8bb6
Author: Dave Brosius 
Authored: Fri Jul 1 16:14:13 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 16:14:13 2016 -0400

--
 lib/licenses/logback-classic-1.1.2.txt | 70 -
 lib/licenses/logback-classic-1.1.3.txt | 70 +
 lib/licenses/logback-core-1.1.2.txt| 70 -
 lib/licenses/logback-core-1.1.3.txt| 70 +
 4 files changed, 140 insertions(+), 140 deletions(-)
--

[2/4] cassandra git commit: update license txt file version numbers

[dbrosius]

update license txt file version numbers


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/da20fece
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/da20fece
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/da20fece

Branch: refs/heads/cassandra-3.0
Commit: da20fece744ab37d7355daa75e1717c08c83e4de
Parents: 82cdc86
Author: Dave Brosius 
Authored: Fri Jul 1 16:08:35 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 16:08:35 2016 -0400

--
 lib/licenses/logback-classic-1.1.2.txt | 70 -
 lib/licenses/logback-classic-1.1.3.txt | 70 +
 lib/licenses/logback-core-1.1.2.txt| 70 -
 lib/licenses/logback-core-1.1.3.txt| 70 +
 4 files changed, 140 insertions(+), 140 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/da20fece/lib/licenses/logback-classic-1.1.2.txt
--
diff --git a/lib/licenses/logback-classic-1.1.2.txt 
b/lib/licenses/logback-classic-1.1.2.txt
deleted file mode 100644
index 79e486c..000
--- a/lib/licenses/logback-classic-1.1.2.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-Eclipse Public License - v 1.0
-
-THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE PUBLIC 
LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM 
CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.
-
-1. DEFINITIONS
-
-"Contribution" means:
-
-a) in the case of the initial Contributor, the initial code and documentation 
distributed under this Agreement, and
-b) in the case of each subsequent Contributor:
-i) changes to the Program, and
-ii) additions to the Program;
-where such changes and/or additions to the Program originate from and are 
distributed by that particular Contributor. A Contribution 'originates' from a 
Contributor if it was added to the Program by such Contributor itself or anyone 
acting on such Contributor's behalf. Contributions do not include additions to 
the Program which: (i) are separate modules of software distributed in 
conjunction with the Program under their own license agreement, and (ii) are 
not derivative works of the Program.
-"Contributor" means any person or entity that distributes the Program.
-
-"Licensed Patents" mean patent claims licensable by a Contributor which are 
necessarily infringed by the use or sale of its Contribution alone or when 
combined with the Program.
-
-"Program" means the Contributions distributed in accordance with this 
Agreement.
-
-"Recipient" means anyone who receives the Program under this Agreement, 
including all Contributors.
-
-2. GRANT OF RIGHTS
-
-a) Subject to the terms of this Agreement, each Contributor hereby grants 
Recipient a non-exclusive, worldwide, royalty-free copyright license to 
reproduce, prepare derivative works of, publicly display, publicly perform, 
distribute and sublicense the Contribution of such Contributor, if any, and 
such derivative works, in source code and object code form.
-b) Subject to the terms of this Agreement, each Contributor hereby grants 
Recipient a non-exclusive, worldwide, royalty-free patent license under 
Licensed Patents to make, use, sell, offer to sell, import and otherwise 
transfer the Contribution of such Contributor, if any, in source code and 
object code form. This patent license shall apply to the combination of the 
Contribution and the Program if, at the time the Contribution is added by the 
Contributor, such addition of the Contribution causes such combination to be 
covered by the Licensed Patents. The patent license shall not apply to any 
other combinations which include the Contribution. No hardware per se is 
licensed hereunder.
-c) Recipient understands that although each Contributor grants the licenses to 
its Contributions set forth herein, no assurances are provided by any 
Contributor that the Program does not infringe the patent or other intellectual 
property rights of any other entity. Each Contributor disclaims any liability 
to Recipient for claims brought by any other entity based on infringement of 
intellectual property rights or otherwise. As a condition to exercising the 
rights and licenses granted hereunder, each Recipient hereby assumes sole 
responsibility to secure any other intellectual property rights needed, if any. 
For example, if a third party patent license is required to allow Recipient to 
distribute the Program, it is Recipient's responsibility to acquire that 
license before distributing the Program.
-d) Each Contributor represents that to its knowledge it has sufficient 
copyright rights in its Contribution, if any, to grant the 

[4/4] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[dbrosius]

Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/db613724
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/db613724
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/db613724

Branch: refs/heads/cassandra-3.0
Commit: db6137249837c255a687db7636471e4f7a15f53b
Parents: 6b24109 65f8bb6
Author: Dave Brosius 
Authored: Fri Jul 1 16:14:13 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 16:14:13 2016 -0400

--
 lib/licenses/logback-classic-1.1.2.txt | 70 -
 lib/licenses/logback-classic-1.1.3.txt | 70 +
 lib/licenses/logback-core-1.1.2.txt| 70 -
 lib/licenses/logback-core-1.1.3.txt| 70 +
 4 files changed, 140 insertions(+), 140 deletions(-)
--

[1/4] cassandra git commit: update license file versions

[dbrosius]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 6b241097b -> db6137249


update license file versions


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/bd6ad43b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/bd6ad43b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/bd6ad43b

Branch: refs/heads/cassandra-3.0
Commit: bd6ad43b9cda883d5aa151fe8580de2f8784e85f
Parents: 40b18d5
Author: Dave Brosius 
Authored: Fri Jul 1 15:53:29 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 15:53:29 2016 -0400

--
 lib/licenses/snappy-java-1.0.5.2.txt | 209 ++
 lib/licenses/snappy-java-1.0.5.txt   | 209 --
 lib/licenses/thrift-server-0.3.5.txt | 202 -
 lib/licenses/thrift-server-0.3.7.txt | 202 +
 4 files changed, 411 insertions(+), 411 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bd6ad43b/lib/licenses/snappy-java-1.0.5.2.txt
--
diff --git a/lib/licenses/snappy-java-1.0.5.2.txt 
b/lib/licenses/snappy-java-1.0.5.2.txt
new file mode 100644
index 000..d5c4984
--- /dev/null
+++ b/lib/licenses/snappy-java-1.0.5.2.txt
@@ -0,0 +1,209 @@
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+  "License" shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  "Legal Entity" shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  "control" means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  "You" (or "Your") shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  "Source" form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  "Object" form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  "Work" shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  "Derivative Works" shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  "Contribution" shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, "submitted"
+  means any form of electronic, verbal, or written communication sent
+  to the Licensor or its representatives, including but not limited to
+  communication on electronic mailing lists, source code control systems,
+  and issue tracking systems that are managed by, or on behalf of, the
+  Licensor for the purpose of discussing and improving the Work, but
+  excluding communication that is conspicuously marked or otherwise
+  designated in writing by the copyright owner as "Not a Contribution."
+
+  "Contributor" shall mean Licensor and any individual or Legal Entity
+ 

[3/4] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[dbrosius]

Merge branch 'cassandra-2.1' into cassandra-2.2

Conflicts:
lib/licenses/crc32ex-0.1.1.txt
lib/licenses/snappy-java-1.0.5.2.txt
lib/licenses/snappy-java-1.0.5.txt
lib/licenses/snappy-java-1.1.1.7.txt
lib/licenses/thrift-server-0.3.5.txt
lib/licenses/thrift-server-0.3.7.txt


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/65f8bb6c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/65f8bb6c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/65f8bb6c

Branch: refs/heads/cassandra-3.0
Commit: 65f8bb6c4635fee4e17b2023915701dce59bc3c8
Parents: da20fec bd6ad43
Author: Dave Brosius 
Authored: Fri Jul 1 16:10:55 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 16:10:55 2016 -0400

--

--

[1/2] cassandra git commit: update license file versions

[dbrosius]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 da20fece7 -> 65f8bb6c4


update license file versions


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/bd6ad43b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/bd6ad43b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/bd6ad43b

Branch: refs/heads/cassandra-2.2
Commit: bd6ad43b9cda883d5aa151fe8580de2f8784e85f
Parents: 40b18d5
Author: Dave Brosius 
Authored: Fri Jul 1 15:53:29 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 15:53:29 2016 -0400

--
 lib/licenses/snappy-java-1.0.5.2.txt | 209 ++
 lib/licenses/snappy-java-1.0.5.txt   | 209 --
 lib/licenses/thrift-server-0.3.5.txt | 202 -
 lib/licenses/thrift-server-0.3.7.txt | 202 +
 4 files changed, 411 insertions(+), 411 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bd6ad43b/lib/licenses/snappy-java-1.0.5.2.txt
--
diff --git a/lib/licenses/snappy-java-1.0.5.2.txt 
b/lib/licenses/snappy-java-1.0.5.2.txt
new file mode 100644
index 000..d5c4984
--- /dev/null
+++ b/lib/licenses/snappy-java-1.0.5.2.txt
@@ -0,0 +1,209 @@
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+  "License" shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  "Legal Entity" shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  "control" means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  "You" (or "Your") shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  "Source" form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  "Object" form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  "Work" shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  "Derivative Works" shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  "Contribution" shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, "submitted"
+  means any form of electronic, verbal, or written communication sent
+  to the Licensor or its representatives, including but not limited to
+  communication on electronic mailing lists, source code control systems,
+  and issue tracking systems that are managed by, or on behalf of, the
+  Licensor for the purpose of discussing and improving the Work, but
+  excluding communication that is conspicuously marked or otherwise
+  designated in writing by the copyright owner as "Not a Contribution."
+
+  "Contributor" shall mean Licensor and any individual or Legal Entity
+ 

[2/2] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[dbrosius]

Merge branch 'cassandra-2.1' into cassandra-2.2

Conflicts:
lib/licenses/crc32ex-0.1.1.txt
lib/licenses/snappy-java-1.0.5.2.txt
lib/licenses/snappy-java-1.0.5.txt
lib/licenses/snappy-java-1.1.1.7.txt
lib/licenses/thrift-server-0.3.5.txt
lib/licenses/thrift-server-0.3.7.txt


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/65f8bb6c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/65f8bb6c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/65f8bb6c

Branch: refs/heads/cassandra-2.2
Commit: 65f8bb6c4635fee4e17b2023915701dce59bc3c8
Parents: da20fec bd6ad43
Author: Dave Brosius 
Authored: Fri Jul 1 16:10:55 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 16:10:55 2016 -0400

--

--

cassandra git commit: update license txt file version numbers

[dbrosius]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 82cdc8617 -> da20fece7


update license txt file version numbers


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/da20fece
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/da20fece
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/da20fece

Branch: refs/heads/cassandra-2.2
Commit: da20fece744ab37d7355daa75e1717c08c83e4de
Parents: 82cdc86
Author: Dave Brosius 
Authored: Fri Jul 1 16:08:35 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 16:08:35 2016 -0400

--
 lib/licenses/logback-classic-1.1.2.txt | 70 -
 lib/licenses/logback-classic-1.1.3.txt | 70 +
 lib/licenses/logback-core-1.1.2.txt| 70 -
 lib/licenses/logback-core-1.1.3.txt| 70 +
 4 files changed, 140 insertions(+), 140 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/da20fece/lib/licenses/logback-classic-1.1.2.txt
--
diff --git a/lib/licenses/logback-classic-1.1.2.txt 
b/lib/licenses/logback-classic-1.1.2.txt
deleted file mode 100644
index 79e486c..000
--- a/lib/licenses/logback-classic-1.1.2.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-Eclipse Public License - v 1.0
-
-THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE PUBLIC 
LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM 
CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.
-
-1. DEFINITIONS
-
-"Contribution" means:
-
-a) in the case of the initial Contributor, the initial code and documentation 
distributed under this Agreement, and
-b) in the case of each subsequent Contributor:
-i) changes to the Program, and
-ii) additions to the Program;
-where such changes and/or additions to the Program originate from and are 
distributed by that particular Contributor. A Contribution 'originates' from a 
Contributor if it was added to the Program by such Contributor itself or anyone 
acting on such Contributor's behalf. Contributions do not include additions to 
the Program which: (i) are separate modules of software distributed in 
conjunction with the Program under their own license agreement, and (ii) are 
not derivative works of the Program.
-"Contributor" means any person or entity that distributes the Program.
-
-"Licensed Patents" mean patent claims licensable by a Contributor which are 
necessarily infringed by the use or sale of its Contribution alone or when 
combined with the Program.
-
-"Program" means the Contributions distributed in accordance with this 
Agreement.
-
-"Recipient" means anyone who receives the Program under this Agreement, 
including all Contributors.
-
-2. GRANT OF RIGHTS
-
-a) Subject to the terms of this Agreement, each Contributor hereby grants 
Recipient a non-exclusive, worldwide, royalty-free copyright license to 
reproduce, prepare derivative works of, publicly display, publicly perform, 
distribute and sublicense the Contribution of such Contributor, if any, and 
such derivative works, in source code and object code form.
-b) Subject to the terms of this Agreement, each Contributor hereby grants 
Recipient a non-exclusive, worldwide, royalty-free patent license under 
Licensed Patents to make, use, sell, offer to sell, import and otherwise 
transfer the Contribution of such Contributor, if any, in source code and 
object code form. This patent license shall apply to the combination of the 
Contribution and the Program if, at the time the Contribution is added by the 
Contributor, such addition of the Contribution causes such combination to be 
covered by the Licensed Patents. The patent license shall not apply to any 
other combinations which include the Contribution. No hardware per se is 
licensed hereunder.
-c) Recipient understands that although each Contributor grants the licenses to 
its Contributions set forth herein, no assurances are provided by any 
Contributor that the Program does not infringe the patent or other intellectual 
property rights of any other entity. Each Contributor disclaims any liability 
to Recipient for claims brought by any other entity based on infringement of 
intellectual property rights or otherwise. As a condition to exercising the 
rights and licenses granted hereunder, each Recipient hereby assumes sole 
responsibility to secure any other intellectual property rights needed, if any. 
For example, if a third party patent license is required to allow Recipient to 
distribute the Program, it is Recipient's responsibility to acquire that 
license before distributing the Program.
-d) Each Contributor represents that to its 

cassandra git commit: update license file versions

[dbrosius]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 40b18d574 -> bd6ad43b9


update license file versions


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/bd6ad43b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/bd6ad43b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/bd6ad43b

Branch: refs/heads/cassandra-2.1
Commit: bd6ad43b9cda883d5aa151fe8580de2f8784e85f
Parents: 40b18d5
Author: Dave Brosius 
Authored: Fri Jul 1 15:53:29 2016 -0400
Committer: Dave Brosius 
Committed: Fri Jul 1 15:53:29 2016 -0400

--
 lib/licenses/snappy-java-1.0.5.2.txt | 209 ++
 lib/licenses/snappy-java-1.0.5.txt   | 209 --
 lib/licenses/thrift-server-0.3.5.txt | 202 -
 lib/licenses/thrift-server-0.3.7.txt | 202 +
 4 files changed, 411 insertions(+), 411 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bd6ad43b/lib/licenses/snappy-java-1.0.5.2.txt
--
diff --git a/lib/licenses/snappy-java-1.0.5.2.txt 
b/lib/licenses/snappy-java-1.0.5.2.txt
new file mode 100644
index 000..d5c4984
--- /dev/null
+++ b/lib/licenses/snappy-java-1.0.5.2.txt
@@ -0,0 +1,209 @@
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+  "License" shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  "Legal Entity" shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  "control" means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  "You" (or "Your") shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  "Source" form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  "Object" form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  "Work" shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  "Derivative Works" shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  "Contribution" shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, "submitted"
+  means any form of electronic, verbal, or written communication sent
+  to the Licensor or its representatives, including but not limited to
+  communication on electronic mailing lists, source code control systems,
+  and issue tracking systems that are managed by, or on behalf of, the
+  Licensor for the purpose of discussing and improving the Work, but
+  excluding communication that is conspicuously marked or otherwise
+  designated in writing by the copyright owner as "Not a Contribution."
+
+  "Contributor" shall mean Licensor and any individual or Legal Entity
+ 

[jira] [Created] (CASSANDRA-12127) Queries with empty ByteBuffer values in clustering column restrictions fail for non-composite compact tables

[Benjamin Lerer (JIRA)]

Benjamin Lerer created CASSANDRA-12127:
--

 Summary: Queries with empty ByteBuffer values in clustering column 
restrictions fail for non-composite compact tables
 Key: CASSANDRA-12127
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12127
 Project: Cassandra
  Issue Type: Bug
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer


For the following table:

{code}
CREATE TABLE myTable (pk int,
  c blob,
  value int,
  PRIMARY KEY (pk, c)) WITH COMPACT STORAGE;
INSERT INTO myTable (pk, c, value) VALUES (1, textAsBlob('1'), 1);
INSERT INTO myTable (pk, c, value) VALUES (1, textAsBlob('2'), 2);
{code}

The query: {{SELECT * FROM myTable WHERE pk = 1 AND c > textAsBlob('');}}

Will result in the following Exception:

{code}
java.lang.ClassCastException: 
org.apache.cassandra.db.composites.Composites$EmptyComposite cannot be cast to 
org.apache.cassandra.db.composites.CellName
at 
org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
at 
org.apache.cassandra.db.composites.AbstractSimpleCellNameType.makeCellName(AbstractSimpleCellNameType.java:125)
at 
org.apache.cassandra.db.composites.AbstractCellNameType.makeCellName(AbstractCellNameType.java:254)
at 
org.apache.cassandra.cql3.statements.SelectStatement.makeExclusiveSliceBound(SelectStatement.java:1206)
at 
org.apache.cassandra.cql3.statements.SelectStatement.applySliceRestriction(SelectStatement.java:1214)
at 
org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1292)
at 
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1259)
at 
org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:299)
[...]
{code}

The query: {{SELECT * FROM myTable WHERE pk = 1 AND c < textAsBlob('');}}

Will return 2 rows instead of 0.

The query: {{SELECT * FROM myTable WHERE pk = 1 AND c = textAsBlob('');}}

{code}
java.lang.AssertionError
at 
org.apache.cassandra.db.composites.SimpleDenseCellNameType.create(SimpleDenseCellNameType.java:60)
at 
org.apache.cassandra.cql3.statements.SelectStatement.addSelectedColumns(SelectStatement.java:853)
at 
org.apache.cassandra.cql3.statements.SelectStatement.getRequestedColumns(SelectStatement.java:846)
at 
org.apache.cassandra.cql3.statements.SelectStatement.makeFilter(SelectStatement.java:583)
at 
org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:383)
at 
org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:253)
[...]
{code}

I checked 2.0 and {{SELECT * FROM myTable  WHERE pk = 1 AND c > 
textAsBlob('');}} works properly but {{SELECT * FROM myTable WHERE pk = 1 AND c 
< textAsBlob('');}} return the same wrong results than in 2.1.
The {{SELECT * FROM myTable WHERE pk = 1 AND c = textAsBlob('');}} is rejected 
if a clear error message: {{Invalid empty value for clustering column of 
COMPACT TABLE}}.

As it is not possible to insert an empty ByteBuffer value within the clustering 
column of a non-composite compact tables those queries do not
have a lot of meaning. {{SELECT * FROM myTable WHERE pk = 1 AND c < 
textAsBlob('');}} and {{SELECT * FROM myTable WHERE pk = 1 AND c = 
textAsBlob('');}} will return nothing
and {{SELECT * FROM myTable WHERE pk = 1 AND c > textAsBlob('');}} will return 
the entire partition (pk = 1).

In my opinion those queries should probably all be rejected as it seems that 
the fact that {{SELECT * FROM myTable  WHERE pk = 1 AND c > textAsBlob('');}} 
was accepted in {{2.0}} was due to a bug.
I am of course open to discussion.



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

[jira] [Commented] (CASSANDRA-11740) Nodes have wrong membership view of the cluster

[Dikang Gu (JIRA)]

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

Dikang Gu commented on CASSANDRA-11740:
---

This happened to one of our 2.2.5 cluster again. one node showed completed 
wrong DC/Rack info in nodetool status.

> Nodes have wrong membership view of the cluster
> ---
>
> Key: CASSANDRA-11740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11740
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Joel Knighton
> Fix For: 2.2.x, 3.x
>
>
> We have a few hundreds nodes across 3 data centers, and we are doing a few 
> millions writes per second into the cluster.
> The problem we found is that there are some nodes (>10) have very wrong view 
> of the cluster.
> For example, we have 3 data centers A, B and C. On the problem nodes, in the 
> output of the 'nodetool status', it shows that ~100 nodes are not in data 
> center A, B, or C. Instead, it shows nodes are in DC1, and rack r1, which is 
> very wrong. And as a result, the node will return wrong results to client 
> requests.
> {code}
> Datacenter: DC1
> ===
> Status=Up/Down
> / State=Normal/Leaving/Joining/Moving
> – Address Load Tokens Owns Host ID Rack
> UN 2401:db00:11:6134:face:0:1:0 509.52 GB 256 ? 
> e24656ac-c3b2-4117-b933-a5b06852c993 r1
> UN 2401:db00:11:b218:face:0:5:0 510.01 GB 256 ? 
> 53da2104-b1b5-4fa5-a3dd-52c7557149f9 r1
> UN 2401:db00:2130:5133:face:0:4d:0 459.75 GB 256 ? 
> ef8311f0-f6b8-491c-904d-baa925cdd7c2 r1
> {code}
> We are using GossipingPropertyFileSnitch.
> Thanks



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

[jira] [Commented] (CASSANDRA-12111) dtest failure in rebuild_test.TestRebuild.rebuild_ranges_test

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-12111:
-

It looks like the [dtest 
PR|https://github.com/riptano/cassandra-dtest/pull/932] for CASSANDRA-10406 was 
merged before the ticket was complete. Additionally, the new dtest isn't 
properly version-gated -- it should only be run on 3.6+.

> dtest failure in rebuild_test.TestRebuild.rebuild_ranges_test
> -
>
> Key: CASSANDRA-12111
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12111
> 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/647/testReport/rebuild_test/TestRebuild/rebuild_ranges_test
> Failed on CassCI build cassandra-2.2_dtest #647



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

[jira] [Commented] (CASSANDRA-12076) Add username to AuthenticationException messages

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-12076:
-

Thanks, the updated patch looks good! I've opened a [dtest 
PR|https://github.com/riptano/cassandra-dtest/pull/1074] for those changes 
(with a slight refactoring), and once that's approved to merge I'll commit this.


> Add username to AuthenticationException messages
> 
>
> Key: CASSANDRA-12076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12076
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Geoffrey Yu
>Assignee: Geoffrey Yu
>Priority: Trivial
> Attachments: 12076-dtest-master.txt, 12076-trunk-v2.txt, 
> 12076-trunk.txt
>
>
> When an {{AuthenticationException}} is thrown, there are a few places where 
> the user that initiated the request is not included in the exception message. 
> It can be useful to have this information included for logging purposes.



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

[jira] [Commented] (CASSANDRA-12098) dtest failure in secondary_indexes_test.TestSecondaryIndexes.test_only_coordinator_chooses_index_for_query

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-12098:
-

I'm going to say that this is unrelated to the actual area under test (i.e. the 
index functionality) because the error in the log is a) symptomatic of a schema 
mismatch on the base table b) occurring during the initial data setup, not the 
main test code. 

This specific failure is the only instance in the available history of both the 
offheap (where this isolated failure occurred) and the main dtest jobs. Given 
that, I'm hesitant to just mark it as flakey. I also failed to repro in 100 
iterations on either job 
([onheap|https://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/156/],
 
[offheap|https://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/158/]).

There have been are some other failures on the offheap jobs recently, so I'll 
spend a bit of time digging there and also go over the attached logs again.


> dtest failure in 
> secondary_indexes_test.TestSecondaryIndexes.test_only_coordinator_chooses_index_for_query
> --
>
> Key: CASSANDRA-12098
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12098
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Sam Tunnicliffe
>  Labels: dtest
> Fix For: 3.x
>
> 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/273/testReport/secondary_indexes_test/TestSecondaryIndexes/test_only_coordinator_chooses_index_for_query
> Failed on CassCI build trunk_offheap_dtest #273
> {code}
> Standard Output
> Unexpected error in node1 log, error: 
> ERROR [MessagingService-Incoming-/127.0.0.3] 2016-06-26 08:11:32,185 
> CassandraDaemon.java:219 - Exception in thread 
> Thread[MessagingService-Incoming-/127.0.0.3,5,main]
> java.lang.RuntimeException: Unknown column b during deserialization
>   at 
> org.apache.cassandra.db.Columns$Serializer.deserialize(Columns.java:433) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.SerializationHeader$Serializer.deserializeForMessaging(SerializationHeader.java:407)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.deserializeHeader(UnfilteredRowIteratorSerializer.java:192)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize30(PartitionUpdate.java:668)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize(PartitionUpdate.java:642)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:349)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:368)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:305)
>  ~[main/:na]
>   at org.apache.cassandra.net.MessageIn.read(MessageIn.java:114) 
> ~[main/:na]
>   at 
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:190)
>  ~[main/:na]
>   at 
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:178)
>  ~[main/:na]
>   at 
> org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:92)
>  ~[main/:na]
> {code}



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

[jira] [Updated] (CASSANDRA-12109) Configuring SSL for JMX connections forces requirement of local truststore

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-12109:

Status: Patch Available  (was: In Progress)

Pushed a fix which restores the pre CASSANDRA-10091 behaviour. It also 
reorganised the JMX section in {{cassandra-env.sh}} slightly, moving the SSL 
options into the {{LOCAL_JMX != yes}} block. One thing to note is that when SSL 
is enabled, it isn't possible to use the same port for both 
{{cassandra.jmx.remote.port}} and {{com.sun.management.jmxremote.rmi.port}}, as 
this causes contention at bind time resulting in {{AlreadyBoundException}}. 
This is not new behaviour though and has been the always been the case AFAIK.

||branch||testall||dtest||
|[12109-3.9|https://github.com/beobal/cassandra/tree/12109-3.9]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-12109-3.9-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-12109-3.9-dtest]|
|[12109-trunk|https://github.com/beobal/cassandra/tree/12109-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-12109-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-12109-trunk-dtest]|



> Configuring SSL for JMX connections forces requirement of local truststore
> --
>
> Key: CASSANDRA-12109
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12109
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Lifecycle, Observability
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 3.x
>
>
> In CASSANDRA-10091 we changed the way the JMX server is constructed such that 
> this is always done programatically, which gives us control over the 
> authentication and authorization mechanisms. Previously, when 
> {{LOCAL_JMX=no}}, Cassandra would allow the JMX setup to be done by the built 
> in JVM agent, which delegates to 
> {{sun.management.jmxremote.ConnectorBootstrap}} to do the actual JMX & RMI 
> setup. 
> This change has introduced a regression when SSL is enabled for JMX 
> connections, namely that now it is not possible to start C* with only the 
> server-side elements of the SSL setup specified. That is, if enabling SSL 
> with {{com.sun.management.jmxremote.ssl=true}}, it should only be necessary 
> to specify a keystore (via {{javax.net.ssl.keyStore}}), and a truststore 
> should only be necessary if client authentication is also enabled 
> ({{com.sun.management.jmxremote.ssl.need.client.auth=true}}). 
> As it is, C* cannot currently startup without a truststore containing the 
> server's own certificate, which is clearly a bug.



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

[jira] [Commented] (CASSANDRA-12126) CAS Reads Inconsistencies

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-12126:
---

cc [~slebresne] and [~jbellis]

> CAS Reads Inconsistencies 
> --
>
> Key: CASSANDRA-12126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12126
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>
> While looking at the CAS code in Cassandra, I found a potential issue with 
> CAS Reads. Here is how it can happen with RF=3
> 1) You issue a CAS Write and it fails in the propose phase. A machine replies 
> true to a propose and saves the commit in accepted filed. The other two 
> machines B and C does not get to the accept phase. 
> Current state is that machine A has this commit in paxos table as accepted 
> but not committed and B and C does not. 
> 2) Issue a CAS Read and it goes to only B and C. You wont be able to read the 
> value written in step 1. This step is as if nothing is inflight. 
> 3) Issue another CAS Read and it goes to A and B. Now we will discover that 
> there is something inflight from A and will propose and commit it with the 
> current ballot. Now we can read the value written in step 1 as part of this 
> CAS read.
> If we skip step 3 and instead run step 4, we will never learn about value 
> written in step 1. 
> 4. Issue a CAS Write and it involves only B and C. This will succeed and 
> commit a different value than step 1. Step 1 value will never be seen again 
> and was never seen before. 
> If you read the Lamport “paxos made simple” paper and read section 2.3. It 
> talks about this issue which is how learners can find out if majority of the 
> acceptors have accepted the proposal. 
> In step 3, it is correct that we propose the value again since we dont know 
> if it was accepted by majority of acceptors. When we ask majority of 
> acceptors, and more than one acceptors but not majority has something in 
> flight, we have no way of knowing if it is accepted by majority of acceptors. 
> So this behavior is correct. 
> However we need to fix step 2, since it caused reads to not be linearizable 
> with respect to writes and other reads. In this case, we know that majority 
> of acceptors have no inflight commit which means we have majority that 
> nothing was accepted by majority. I think we should run a propose step here 
> with empty commit and that will cause write written in step 1 to not be 
> visible ever after. 
> With this fix, we will either see data written in step 1 on next serial read 
> or will never see it which is what we want. 



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

[jira] [Created] (CASSANDRA-12126) CAS Reads Inconsistencies

[sankalp kohli (JIRA)]

sankalp kohli created CASSANDRA-12126:
-

 Summary: CAS Reads Inconsistencies 
 Key: CASSANDRA-12126
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12126
 Project: Cassandra
  Issue Type: Bug
Reporter: sankalp kohli


While looking at the CAS code in Cassandra, I found a potential issue with CAS 
Reads. Here is how it can happen with RF=3

1) You issue a CAS Write and it fails in the propose phase. A machine replies 
true to a propose and saves the commit in accepted filed. The other two 
machines B and C does not get to the accept phase. 

Current state is that machine A has this commit in paxos table as accepted but 
not committed and B and C does not. 

2) Issue a CAS Read and it goes to only B and C. You wont be able to read the 
value written in step 1. This step is as if nothing is inflight. 

3) Issue another CAS Read and it goes to A and B. Now we will discover that 
there is something inflight from A and will propose and commit it with the 
current ballot. Now we can read the value written in step 1 as part of this CAS 
read.

If we skip step 3 and instead run step 4, we will never learn about value 
written in step 1. 

4. Issue a CAS Write and it involves only B and C. This will succeed and commit 
a different value than step 1. Step 1 value will never be seen again and was 
never seen before. 



If you read the Lamport “paxos made simple” paper and read section 2.3. It 
talks about this issue which is how learners can find out if majority of the 
acceptors have accepted the proposal. 

In step 3, it is correct that we propose the value again since we dont know if 
it was accepted by majority of acceptors. When we ask majority of acceptors, 
and more than one acceptors but not majority has something in flight, we have 
no way of knowing if it is accepted by majority of acceptors. So this behavior 
is correct. 

However we need to fix step 2, since it caused reads to not be linearizable 
with respect to writes and other reads. In this case, we know that majority of 
acceptors have no inflight commit which means we have majority that nothing was 
accepted by majority. I think we should run a propose step here with empty 
commit and that will cause write written in step 1 to not be visible ever 
after. 

With this fix, we will either see data written in step 1 on next serial read or 
will never see it which is what we want. 




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

[jira] [Updated] (CASSANDRA-12109) Configuring SSL for JMX connections forces requirement of local truststore

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-12109:

Fix Version/s: (was: 3.0.x)

> Configuring SSL for JMX connections forces requirement of local truststore
> --
>
> Key: CASSANDRA-12109
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12109
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Lifecycle, Observability
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 3.x
>
>
> In CASSANDRA-10091 we changed the way the JMX server is constructed such that 
> this is always done programatically, which gives us control over the 
> authentication and authorization mechanisms. Previously, when 
> {{LOCAL_JMX=no}}, Cassandra would allow the JMX setup to be done by the built 
> in JVM agent, which delegates to 
> {{sun.management.jmxremote.ConnectorBootstrap}} to do the actual JMX & RMI 
> setup. 
> This change has introduced a regression when SSL is enabled for JMX 
> connections, namely that now it is not possible to start C* with only the 
> server-side elements of the SSL setup specified. That is, if enabling SSL 
> with {{com.sun.management.jmxremote.ssl=true}}, it should only be necessary 
> to specify a keystore (via {{javax.net.ssl.keyStore}}), and a truststore 
> should only be necessary if client authentication is also enabled 
> ({{com.sun.management.jmxremote.ssl.need.client.auth=true}}). 
> As it is, C* cannot currently startup without a truststore containing the 
> server's own certificate, which is clearly a bug.



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

[jira] [Commented] (CASSANDRA-11638) Add cassandra-stress test source

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-11638:
---

+1, ready to commit.

Note to committer: use the branch at 
[jkni/stress-tests-jkni|https://github.com/jkni/cassandra/commits/stress-tests-jkni].
 This should only go to trunk.

> Add cassandra-stress test source
> 
>
> Key: CASSANDRA-11638
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11638
> Project: Cassandra
>  Issue Type: Test
>  Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Minor
>  Labels: stress
> Fix For: 3.x
>
> Attachments: 
> 0001-Add-a-test-source-directory-for-Cassandra-stress.patch
>
>
> This adds a test root for cassandra-stress and a couple of noddy tests for a 
> jira I did last week to prove it works / fails the build if they fail.
> I put the source in {{tools/stress/test/unit}} and the classes in 
> {{build/test/stress-classes}} (rather than putting them in with the main test 
> classes).
> Patch attached or at: https://github.com/chbatey/cassandra-1/tree/stress-tests



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

[jira] [Updated] (CASSANDRA-11638) Add cassandra-stress test source

[Anonymous (JIRA)]

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

Anonymous updated CASSANDRA-11638:
--
Status: Ready to Commit  (was: Patch Available)

> Add cassandra-stress test source
> 
>
> Key: CASSANDRA-11638
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11638
> Project: Cassandra
>  Issue Type: Test
>  Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Minor
>  Labels: stress
> Fix For: 3.x
>
> Attachments: 
> 0001-Add-a-test-source-directory-for-Cassandra-stress.patch
>
>
> This adds a test root for cassandra-stress and a couple of noddy tests for a 
> jira I did last week to prove it works / fails the build if they fail.
> I put the source in {{tools/stress/test/unit}} and the classes in 
> {{build/test/stress-classes}} (rather than putting them in with the main test 
> classes).
> Patch attached or at: https://github.com/chbatey/cassandra-1/tree/stress-tests



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

[jira] [Commented] (CASSANDRA-11904) Exception in thread Thread[CompactionExecutor:13358,1,main] java.lang.AssertionError: Memory was freed

[Dan Kinder (JIRA)]

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

Dan Kinder commented on CASSANDRA-11904:


Sorry I don't have any other logs. We had a bunch of issues aside from this one 
so we simply rolled it back and didn't investigate debug logs.

> Exception in thread Thread[CompactionExecutor:13358,1,main] 
> java.lang.AssertionError: Memory was freed
> --
>
> Key: CASSANDRA-11904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11904
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Valentin Martinjuk
>Assignee: Marcus Eriksson
> Attachments: system.log.2016-06-10_0514
>
>
> We have Cassandra cluster 2.2.5 with two datacenters(3 nodes each).
> We observe ERRORs below on all nodes. The ERROR is repeated every minute. 
> No any complains from customers. Do we have any chance to fix it without 
> restart?
> {code}
> ERROR [CompactionExecutor:13996] 2016-05-26 21:20:46,700 
> CassandraDaemon.java:185 - Exception in thread 
> Thread[CompactionExecutor:13996,1,main]
> java.lang.AssertionError: Memory was freed
> at 
> org.apache.cassandra.io.util.SafeMemory.checkBounds(SafeMemory.java:103) 
> ~[apache-cassandra-2.2.5.jar:2.2.5]
> at org.apache.cassandra.io.util.Memory.getInt(Memory.java:292) 
> ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.IndexSummary.getPositionInSummary(IndexSummary.java:148)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.IndexSummary.fillTemporaryKey(IndexSummary.java:162)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.IndexSummary.binarySearch(IndexSummary.java:121)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.getSampleIndexesForRanges(SSTableReader.java:1398)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.estimatedKeysForRanges(SSTableReader.java:1354)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionStrategy.worthDroppingTombstones(AbstractCompactionStrategy.java:403)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.findDroppableSSTable(LeveledCompactionStrategy.java:412)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:101)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.db.compaction.WrappingCompactionStrategy.getNextBackgroundTask(WrappingCompactionStrategy.java:88)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:250)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_74]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_74]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_74]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_74]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_74]
> ERROR [CompactionExecutor:13996] 2016-05-26 21:21:46,702 
> CassandraDaemon.java:185 - Exception in thread 
> Thread[CompactionExecutor:13996,1,main]
> java.lang.AssertionError: Memory was freed
> at 
> org.apache.cassandra.io.util.SafeMemory.checkBounds(SafeMemory.java:103) 
> ~[apache-cassandra-2.2.5.jar:2.2.5]
> at org.apache.cassandra.io.util.Memory.getInt(Memory.java:292) 
> ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.IndexSummary.getPositionInSummary(IndexSummary.java:148)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.IndexSummary.fillTemporaryKey(IndexSummary.java:162)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.IndexSummary.binarySearch(IndexSummary.java:121)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.getSampleIndexesForRanges(SSTableReader.java:1398)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.estimatedKeysForRanges(SSTableReader.java:1354)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> 

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0.8 [deleted] 8b21d9e9e

[jira] [Updated] (CASSANDRA-11670) Error while waiting on bootstrap to complete. Bootstrap will have to be restarted. Stream failed

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-11670:

Status: Awaiting Feedback  (was: In Progress)

> Error while waiting on bootstrap to complete. Bootstrap will have to be 
> restarted. Stream failed
> 
>
> Key: CASSANDRA-11670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11670
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Streaming and Messaging
>Reporter: Anastasia Osintseva
>Assignee: Paulo Motta
> Fix For: 3.0.x
>
>
> I have in cluster 2 DC, in each DC - 2 Nodes. I wanted to add 1 node to each 
> DC. One node has been added successfully after I had made scrubing. 
> Now I'm trying to add node to another DC, but get error: 
> org.apache.cassandra.streaming.StreamException: Stream failed. 
> After scrubing and repair I get the same error.  
> {noformat}
> ERROR [StreamReceiveTask:5] 2016-04-27 00:33:21,082 Keyspace.java:492 - 
> Unknown exception caught while attempting to update MaterializedView! 
> messages_dump.messages
> java.lang.IllegalArgumentException: Mutation of 34974901 bytes is too large 
> for the maxiumum size of 33554432
>   at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:264) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:469) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:384) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:205) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:217) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.batchlog.BatchlogManager.store(BatchlogManager.java:146) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:724) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:149)
>  ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:487) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:384) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:205) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:217) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.applyUnsafe(Mutation.java:236) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:169)
>  [apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_11]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_11]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_11]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_11]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_11]
> ERROR [StreamReceiveTask:5] 2016-04-27 00:33:21,082 
> StreamReceiveTask.java:214 - Error applying streamed data: 
> java.lang.IllegalArgumentException: Mutation of 34974901 bytes is too large 
> for the maxiumum size of 33554432
>   at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:264) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:469) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:384) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:205) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:217) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.batchlog.BatchlogManager.store(BatchlogManager.java:146) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:724) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:149)
>  ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:487) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:384) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 

[jira] [Comment Edited] (CASSANDRA-11670) Error while waiting on bootstrap to complete. Bootstrap will have to be restarted. Stream failed

[Paulo Motta (JIRA)]

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

Paulo Motta edited comment on CASSANDRA-11670 at 7/1/16 3:31 PM:
-

Instead of having separate paths for small and large batches, I think it's 
simpler and cleaner to redesign our batchlog table to expand the current 
{{list}} column into clustered rows, so we can append mutations 
individually to the same batchlog partition without being restricted to 
{{max_mutation_size_in_kb}} for the total batchlog size.

The idea is to have something like
{noformat}
CREATE TABLE Batches (
id timeuuid,
idx bigint,
mutation blob,
version int static,
active boolean static,
PRIMARY KEY ((id), idx)
)
{noformat}

So, creating a batch is a matter of populating a partition with mutations and 
then setting the {{active}} flag to true, what will indicate the batch is ready 
to be potentially replayed (building on [~carlyeks]'s suggestion).

In order to verify the potential performance impact of this change, I ran 3 
cstar tests with 3 different implementations and the throughput/latency doesn't 
seem to be impacted with this change.

The 3 compared branches are:
* [3.0-noreplay|https://github.com/pauloricardomg/cassandra/tree/3.0-noreplay] 
(3.0 with disabled batchlog replay - so it's comparable with others)
* [11670-v2|https://github.com/pauloricardomg/cassandra/tree/3.0-11670-v2] 
(table above)
* [11670-v3|https://github.com/pauloricardomg/cassandra/tree/3.0-11670-v3] 
(alternative design where table is clustered, but mutations are stored as a 
{{list}} in order to have fewer rows - schema below)
** {noformat}
CREATE TABLE Batches (
id timeuuid,
idx bigint,"
mutations list,"
version int static,"
active boolean static,"
PRIMARY KEY ((id), idx)
)
{noformat}

The cstar tests are:
* [1 materialized 
view|http://cstar.datastax.com/graph?command=one_job=01de5e5e-3ed3-11e6-8a53-0256e416528f=op_rate=1_user=1_aggregates=true=0=2690.27=0=70239.4]
* [3 materialized 
views|http://cstar.datastax.com/graph?command=one_job=0a632460-3edd-11e6-85ce-0256e416528f=op_rate=1_user=1_aggregates=true=0=5128.86=0=2832.5]
* [cqlstress-example.yaml (multi-partition 
batches)|http://cstar.datastax.com/graph?command=one_job=0a632460-3edd-11e6-85ce-0256e416528f=op_rate=1_user=1_aggregates=true=0=5128.86=0=2832.5]

As said before, from these results there doesn't seem to be any impact on 
throughput/latency from switching to this approach. If we decide to go with 
this little change will be necessary in the batchlog handling code to support 
it, most of the effort will probably on supporting upgrade to this new scheme.

I'm not sure if there any other potential issues with turning the batchlog into 
a wide table and applying mutations individually, but if not I think we should 
go with this approach. WDYT [~carlyeks] [~iamaleksey]?


was (Author: pauloricardomg):
Instead of having separate paths for small and large batches, I think it's 
simpler and cleaner to redesign our batchlog table to expand the current 
{{list}} column into clustered rows, so we can append mutations 
individually to the same batchlog partition without being restricted to 
{{max_mutation_size_in_kb}} for the total batchlog size.

The idea is to have something like
{noformat}
CREATE TABLE Batches (
id timeuuid,
idx bigint,
mutation blob,
version int static,
active boolean static,
PRIMARY KEY ((id), idx)
)
{noformat}

So, creating a batch is a matter of populating a partition with mutations and 
then setting the {{active}} flag to true, what will indicate the batch is ready 
to be potentially replayed.

In order to verify the potential performance impact of this change, I ran 3 
cstar tests with 3 different implementations and the throughput/latency doesn't 
seem to be impacted with this change.

The 3 compared branches are:
* [3.0-noreplay|https://github.com/pauloricardomg/cassandra/tree/3.0-noreplay] 
(3.0 with disabled batchlog replay - so it's comparable with others)
* [11670-v2|https://github.com/pauloricardomg/cassandra/tree/3.0-11670-v2] 
(table above)
* [11670-v3|https://github.com/pauloricardomg/cassandra/tree/3.0-11670-v3] 
(alternative design where table is clustered, but mutations are stored as a 
{{list}} in order to have fewer rows - schema below)
** {noformat}
CREATE TABLE Batches (
id timeuuid,
idx bigint,"
mutations list,"
version int static,"
active boolean static,"
PRIMARY KEY ((id), idx)
)
{noformat}

The cstar tests are:
* [1 materialized 
view|http://cstar.datastax.com/graph?command=one_job=01de5e5e-3ed3-11e6-8a53-0256e416528f=op_rate=1_user=1_aggregates=true=0=2690.27=0=70239.4]
* [3 materialized 
views|http://cstar.datastax.com/graph?command=one_job=0a632460-3edd-11e6-85ce-0256e416528f=op_rate=1_user=1_aggregates=true=0=5128.86=0=2832.5]
* 

[jira] [Commented] (CASSANDRA-11670) Error while waiting on bootstrap to complete. Bootstrap will have to be restarted. Stream failed

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11670:
-

Instead of having separate paths for small and large batches, I think it's 
simpler and cleaner to redesign our batchlog table to expand the current 
{{list}} column into clustered rows, so we can append mutations 
individually to the same batchlog partition without being restricted to 
{{max_mutation_size_in_kb}} for the total batchlog size.

The idea is to have something like
{noformat}
CREATE TABLE Batches (
id timeuuid,
idx bigint,
mutation blob,
version int static,
active boolean static,
PRIMARY KEY ((id), idx)
)
{noformat}

So, creating a batch is a matter of populating a partition with mutations and 
then setting the {{active}} flag to true, what will indicate the batch is ready 
to be potentially replayed.

In order to verify the potential performance impact of this change, I ran 3 
cstar tests with 3 different implementations and the throughput/latency doesn't 
seem to be impacted with this change.

The 3 compared branches are:
* [3.0-noreplay|https://github.com/pauloricardomg/cassandra/tree/3.0-noreplay] 
(3.0 with disabled batchlog replay - so it's comparable with others)
* [11670-v2|https://github.com/pauloricardomg/cassandra/tree/3.0-11670-v2] 
(table above)
* [11670-v3|https://github.com/pauloricardomg/cassandra/tree/3.0-11670-v3] 
(alternative design where table is clustered, but mutations are stored as a 
{{list}} in order to have fewer rows - schema below)
** {noformat}
CREATE TABLE Batches (
id timeuuid,
idx bigint,"
mutations list,"
version int static,"
active boolean static,"
PRIMARY KEY ((id), idx)
)
{noformat}

The cstar tests are:
* [1 materialized 
view|http://cstar.datastax.com/graph?command=one_job=01de5e5e-3ed3-11e6-8a53-0256e416528f=op_rate=1_user=1_aggregates=true=0=2690.27=0=70239.4]
* [3 materialized 
views|http://cstar.datastax.com/graph?command=one_job=0a632460-3edd-11e6-85ce-0256e416528f=op_rate=1_user=1_aggregates=true=0=5128.86=0=2832.5]
* [cqlstress-example.yaml (multi-partition 
batches)|http://cstar.datastax.com/graph?command=one_job=0a632460-3edd-11e6-85ce-0256e416528f=op_rate=1_user=1_aggregates=true=0=5128.86=0=2832.5]

As said before, from these results there doesn't seem to be any impact on 
throughput/latency from switching to this approach. If we decide to go with 
this little change will be necessary in the batchlog handling code to support 
it, most of the effort will probably on supporting upgrade to this new scheme.

I'm not sure if there any other potential issues with turning the batchlog into 
a wide table and applying mutations individually, but if not I think we should 
go with this approach. WDYT [~carlyeks] [~iamaleksey]?

> Error while waiting on bootstrap to complete. Bootstrap will have to be 
> restarted. Stream failed
> 
>
> Key: CASSANDRA-11670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11670
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Streaming and Messaging
>Reporter: Anastasia Osintseva
>Assignee: Paulo Motta
> Fix For: 3.0.x
>
>
> I have in cluster 2 DC, in each DC - 2 Nodes. I wanted to add 1 node to each 
> DC. One node has been added successfully after I had made scrubing. 
> Now I'm trying to add node to another DC, but get error: 
> org.apache.cassandra.streaming.StreamException: Stream failed. 
> After scrubing and repair I get the same error.  
> {noformat}
> ERROR [StreamReceiveTask:5] 2016-04-27 00:33:21,082 Keyspace.java:492 - 
> Unknown exception caught while attempting to update MaterializedView! 
> messages_dump.messages
> java.lang.IllegalArgumentException: Mutation of 34974901 bytes is too large 
> for the maxiumum size of 33554432
>   at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:264) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:469) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:384) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:205) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:217) 
> [apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.batchlog.BatchlogManager.store(BatchlogManager.java:146) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:724) 
> ~[apache-cassandra-3.0.5.jar:3.0.5]
>   at 
> 

[jira] [Commented] (CASSANDRA-7396) Allow selecting Map key, List index

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-7396:
-

Remarks on the patch:
* As this basically uses terms in select clauses, this should be rebased on top 
of CASSANDRA-10783, rather than redoing it's own thing. I'm in particular not 
at all a fan of the "dynamic" thing, especially when have already the concept 
of {{Terminal}} and {{NonTerminal}} terms to deal with the same thing.
* This only allows element/slice selection directly on a column name, and 
without nesting, which is imo overly restrictive (we don't have that 
restriction for field selection for instance). That does change a bit how we 
want this to work.
* The way {{SelectStatement}} deals with {{ColumnFilter}} feels a bit hacky to 
me. I understand that we cannot always compute the {{ColumnFilter}} at 
preparation time anymore, and that we may want to avoid doing it at execution 
time if we can, but I think that could be more cleanly abstracted.
* The patch seems to use {{null}} to handle the absence of {{from}} or {{to}} 
in the slice syntax. I'm not sure about that. I think we should refuse {{null}} 
but accept {{unset}} and make it equivalent to not having a value. That's more 
logical imo.
* I'm not sure about passing the Cell to the {{ResultSetBuilder}}. First 
because having an {{Object}} array is somewhat ugly, but also because I think 
trying to push along this line in CASSANDRA-7826 will get complicated. I think 
it's simpler to serialize what we get from the storage blindly, and let 
selector extract subselections from the serialized form aferwards (which they 
can do without deserializing, working directly on the serialized form).
* It's a bit of an edge case, but {{SELECT m, m\['4'..'6'\] FROM ...}} wasn't 
working as expected, as the {{ColumnFilter}} only ended up querying the 
selected slice, ignoring the full column selection.
* There is also a problem with {{SELECT m\[3..4\] FROM ...}} because the parser 
parse {{3.}} as a float and fails to recognize the slice syntax afterwards. Mor 
eon tat below.

I took a shot at fixing those 
[here|https://github.com/pcmanus/cassandra/commits/7396-trunk], which ends up 
looking quite a bit different. I did however struggled with ANTLR, and there is 
currently still a few parsing issue that prevent this from being "patch 
available":
# The problem with {{SELECT m\[3..4\] FROM ...}} where {{3.}} is lexed as a 
float. I tried to change the lexer using ANTLR a syntactic predicate to 
presumably not lex {{3.}} as a float if it's followed by another {{.}}, but I 
must have gotten that wrong as it didn't work. I also tried fixing in the 
parser, making the accept '\[' term '.' term '\]'  and rejecting that 
afterwards if the left-most term isn't what it should, but ANTLR ended with 
crazy conflicts. Anyway, I'm currently a bit out of options.
# For some weird reason, ANTLR also started complaining about {{DISTINCT}} and 
{{JSON}} not being reserved function names. That it complains isn't all that 
weird, since after all, something like {{SELECT DISTINCT (3, 4) FROM .. }} *is* 
ambiguous (it could either be a DISTINCT query on a tuple, or a function call), 
but what is weird is that it complains following the changes made by that 
patch, which ought to be unrelated. It should have complained in 
CASSANDRA-10783 where the ambiguity was created, but somehow didn't. I've 
currently resolved that by make the keywords reserved, which is strictly 
speaking a potential breaking change. That said, that's one problem I'm 
personally willing to live with: in hindsight it sounds like a bad idea to not 
have those be reserved, and there is an upgrade path for the few users that 
might use them as unreserved.
# I wasn't able to make ANTLR accept the new syntax in it's more general form. 
Basically, we only allow column names on the left-hand side of the new syntax. 
That is, we accept {{SELECT m\[3\]\['foo'..'bar'\] FROM}}, but not {{SELECT 
f(c)\[3\]}} for instance. I'd really rather avoid that limitation as we don't 
have it for UDT field selection, but I was unable to have ANTLR be reasonable.

Anyway, the patch is currently "blocked" by those parsing issues and if someone 
knowledgeable with ANTLR feels like having a look, I certainly wouldn't mind.


> Allow selecting Map key, List index
> ---
>
> Key: CASSANDRA-7396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7396
> Project: Cassandra
>  Issue Type: New Feature
>  Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Robert Stupp
>  Labels: cql, docs-impacting
> Fix For: 3.x
>
> Attachments: 7396_unit_tests.txt
>
>
> Allow "SELECT map['key]" and "SELECT list[index]."  (Selecting a UDT subfield 
> 

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Tags:  refs/tags/3.0.8-tentative [created] 8b21d9e9e

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Tags:  refs/tags/3.0.8-tentative [deleted] 1cff5faea

cassandra git commit: Revert "Merge branch 'cassandra-2.2' into cassandra-3.0"

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0.8 [created] 8b21d9e9e


Revert "Merge branch 'cassandra-2.2' into cassandra-3.0"

This reverts commit 2395f9e4678c76fa288675c57496259515efef90, reversing
changes made to 70059726f08a98ea21af91ce3855bf62f6f4b652.


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8b21d9e9
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8b21d9e9
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8b21d9e9

Branch: refs/heads/cassandra-3.0.8
Commit: 8b21d9e9e975ea07023ae6ec4c04d997006c1a0a
Parents: 1cff5fa
Author: T Jake Luciani 
Authored: Fri Jul 1 11:09:35 2016 -0400
Committer: T Jake Luciani 
Committed: Fri Jul 1 11:09:35 2016 -0400

--
 conf/cassandra-env.ps1 | 1 -
 conf/cassandra-env.sh  | 1 -
 2 files changed, 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8b21d9e9/conf/cassandra-env.ps1
--
diff --git a/conf/cassandra-env.ps1 b/conf/cassandra-env.ps1
index 80645f9..794189f 100644
--- a/conf/cassandra-env.ps1
+++ b/conf/cassandra-env.ps1
@@ -327,7 +327,6 @@ Function SetCassandraEnvironment
 # times. If in doubt, and if you do not particularly want to tweak, go
 # 100 MB per physical CPU core.
 
-New-Item -Force -ItemType directory -Path $env:CASSANDRA_HOME/logs/
 #GC log path has to be defined here since it needs to find CASSANDRA_HOME
 $env:JVM_OPTS="$env:JVM_OPTS -Xloggc:""$env:CASSANDRA_HOME/logs/gc.log"""
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8b21d9e9/conf/cassandra-env.sh
--
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index 568448b..44fe110 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -121,7 +121,6 @@ case "$jvm" in
 ;;
 esac
 
-mkdir -p ${CASSANDRA_HOME}/logs/
 #GC log path has to be defined here because it needs to access CASSANDRA_HOME
 JVM_OPTS="$JVM_OPTS -Xloggc:${CASSANDRA_HOME}/logs/gc.log"
 

[jira] [Resolved] (CASSANDRA-12110) Cassandra udf's calling in java code

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne resolved CASSANDRA-12110.
--
Resolution: Invalid

I think the reported answered its own question, and questions about usage 
should go the mailing list in the first place anyway, so closing.

> Cassandra udf's calling in java code
> 
>
> Key: CASSANDRA-12110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12110
> Project: Cassandra
>  Issue Type: Test
>  Components: CQL
> Environment: Linux and java
>Reporter: Raghavendra Pinninti
>Priority: Minor
>  Labels: cassandra, cqlsh, java, triggers, udf
> Fix For: 3.0.8
>
>
> I created two udf's and one trigger in Cassandra(3.2) cqlsh.How to check 
> existed udf's and triggers in cassandra? How can I call them through datastax 
> java driver in java code?



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

[jira] [Updated] (CASSANDRA-12107) Fix range scans for table with live static rows

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-12107:
-
Status: Patch Available  (was: Open)

> Fix range scans for table with live static rows
> ---
>
> Key: CASSANDRA-12107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12107
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Sharvanath Pathak
>  Labels: patch-available
> Fix For: 3.0.8
>
> Attachments: repro
>
>
> We were seeing some weird behaviour with limit based scan queries. In 
> particular, we see the following:
> {noformat}
> $ cqlsh -k sd -e "consistency local_quorum; SELECT uuid, token(uuid) FROM 
> files WHERE token(uuid) >= token('6b470c3e43ee06d1') limit 2"
> Consistency level set to LOCAL_QUORUM.
>  uuid | system.token(uuid)
> --+--
>  6b470c3e43ee06d1 | -9218823070349964862
>  484b091ca97803cd | -8954822859271125729
> (2 rows)
> $ cqlsh -k sd -e "consistency local_quorum; SELECT uuid, token(uuid) FROM 
> files WHERE token(uuid) > token('6b470c3e43ee06d1') limit 1"
> Consistency level set to LOCAL_QUORUM.
>  uuid | system.token(uuid)
> --+--
>  c348aaec2f1e4b85 | -9218781105444826588
> {noformat}
> In the table uuid is partition key, and it has a clustering key as well.
> So the uuid "c348aaec2f1e4b85" should be the second one in the limit query. 
> After some investigation, it seems to me like the issue is in the way 
> DataLimits handles static rows. Here is a patch for trunk 
> (https://github.com/sharvanath/cassandra/commit/9a460d40e55bd7e3604d987ed4df5c8c2e03ffdc)
>  which seems to fix it for me. Please take a look, seems like a pretty 
> critical issue to me.
> I have forked the dtests for it as well. However, since trunk has some 
> failures already, I'm not fully sure how to infer the results.
> http://cassci.datastax.com/view/Dev/view/sharvanath/job/sharvanath-fixScan-dtest/
> http://cassci.datastax.com/view/Dev/view/sharvanath/job/sharvanath-fixScan-testall/



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

[jira] [Updated] (CASSANDRA-12105) ThriftServer.stop is not thread safe

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-12105:
--
Reviewer: Aleksey Yeschenko

> ThriftServer.stop is not thread safe
> 
>
> Key: CASSANDRA-12105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12105
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Brian Wawok
>Priority: Critical
> Fix For: 2.1.x
>
> Attachments: patch1.txt, patch2.txt
>
>
> There is a small thread safety issue in ThriftServer.stop(). If we have 
> multiple calls to stop, one thread may NPE or otherwise do bad stuff.



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

[jira] [Updated] (CASSANDRA-12101) DESCRIBE INDEX: missing quotes for case-sensitive index name

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-12101:
-
Assignee: Stefania

> DESCRIBE INDEX: missing quotes for case-sensitive index name
> 
>
> Key: CASSANDRA-12101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12101
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Julien
>Assignee: Stefania
>Priority: Minor
>  Labels: cqlsh, lhf
>
> Create a custom index with a case-sensitive name.
> The result of the DESCRIBE INDEX command does not have quotes around the 
> index name. As a result, the index cannot be recreated with this output.



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

[jira] [Updated] (CASSANDRA-12101) DESCRIBE INDEX: missing quotes for case-sensitive index name

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-12101:
-
Labels: cqlsh lhf  (was: cqlsh)

> DESCRIBE INDEX: missing quotes for case-sensitive index name
> 
>
> Key: CASSANDRA-12101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12101
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Julien
>Priority: Minor
>  Labels: cqlsh, lhf
>
> Create a custom index with a case-sensitive name.
> The result of the DESCRIBE INDEX command does not have quotes around the 
> index name. As a result, the index cannot be recreated with this output.



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

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2.7 [deleted] 092054170

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Tags:  refs/tags/2.2.7-tentative [created] 092054170

cassandra git commit: Revert "Fix GC logging on first start"

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2.7 [created] 092054170


Revert "Fix GC logging on first start"

This reverts commit 3a61c106595745694a73970c780c3713776f4362.


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/09205417
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/09205417
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/09205417

Branch: refs/heads/cassandra-2.2.7
Commit: 092054170ec3daf92ec494a0db295037d3563229
Parents: ea8c430
Author: Josh McKenzie 
Authored: Thu Jun 30 16:31:43 2016 -0400
Committer: T Jake Luciani 
Committed: Fri Jul 1 10:32:50 2016 -0400

--
 conf/cassandra-env.ps1 | 1 -
 conf/cassandra-env.sh  | 1 -
 2 files changed, 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/09205417/conf/cassandra-env.ps1
--
diff --git a/conf/cassandra-env.ps1 b/conf/cassandra-env.ps1
index 60d15bb..321a9ca 100644
--- a/conf/cassandra-env.ps1
+++ b/conf/cassandra-env.ps1
@@ -425,7 +425,6 @@ Function SetCassandraEnvironment
 $env:JVM_OPTS="$env:JVM_OPTS -XX:+PrintPromotionFailure"
 # $env:JVM_OPTS="$env:JVM_OPTS -XX:PrintFLSStatistics=1"
 
-New-Item -Force -ItemType directory -Path $env:CASSANDRA_HOME/logs/
 $env:JVM_OPTS="$env:JVM_OPTS -Xloggc:""$env:CASSANDRA_HOME/logs/gc.log"""
 $env:JVM_OPTS="$env:JVM_OPTS -XX:+UseGCLogFileRotation"
 $env:JVM_OPTS="$env:JVM_OPTS -XX:NumberOfGCLogFiles=10"

http://git-wip-us.apache.org/repos/asf/cassandra/blob/09205417/conf/cassandra-env.sh
--
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index 5d2330c..b519b76 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -241,7 +241,6 @@ JVM_OPTS="$JVM_OPTS -XX:+PrintGCApplicationStoppedTime"
 JVM_OPTS="$JVM_OPTS -XX:+PrintPromotionFailure"
 #JVM_OPTS="$JVM_OPTS -XX:PrintFLSStatistics=1"
 
-mkdir -p ${CASSANDRA_HOME}/logs/
 JVM_OPTS="$JVM_OPTS -Xloggc:${CASSANDRA_HOME}/logs/gc.log"
 JVM_OPTS="$JVM_OPTS -XX:+UseGCLogFileRotation"
 JVM_OPTS="$JVM_OPTS -XX:NumberOfGCLogFiles=10"

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Tags:  refs/tags/2.2.7-tentative [deleted] ea8c43012

[jira] [Commented] (CASSANDRA-11904) Exception in thread Thread[CompactionExecutor:13358,1,main] java.lang.AssertionError: Memory was freed

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-11904:
-

[~dankinder] do you still have the debug logs?

> Exception in thread Thread[CompactionExecutor:13358,1,main] 
> java.lang.AssertionError: Memory was freed
> --
>
> Key: CASSANDRA-11904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11904
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Valentin Martinjuk
>Assignee: Marcus Eriksson
> Attachments: system.log.2016-06-10_0514
>
>
> We have Cassandra cluster 2.2.5 with two datacenters(3 nodes each).
> We observe ERRORs below on all nodes. The ERROR is repeated every minute. 
> No any complains from customers. Do we have any chance to fix it without 
> restart?
> {code}
> ERROR [CompactionExecutor:13996] 2016-05-26 21:20:46,700 
> CassandraDaemon.java:185 - Exception in thread 
> Thread[CompactionExecutor:13996,1,main]
> java.lang.AssertionError: Memory was freed
> at 
> org.apache.cassandra.io.util.SafeMemory.checkBounds(SafeMemory.java:103) 
> ~[apache-cassandra-2.2.5.jar:2.2.5]
> at org.apache.cassandra.io.util.Memory.getInt(Memory.java:292) 
> ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.IndexSummary.getPositionInSummary(IndexSummary.java:148)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.IndexSummary.fillTemporaryKey(IndexSummary.java:162)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.IndexSummary.binarySearch(IndexSummary.java:121)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.getSampleIndexesForRanges(SSTableReader.java:1398)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.estimatedKeysForRanges(SSTableReader.java:1354)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionStrategy.worthDroppingTombstones(AbstractCompactionStrategy.java:403)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.findDroppableSSTable(LeveledCompactionStrategy.java:412)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:101)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.db.compaction.WrappingCompactionStrategy.getNextBackgroundTask(WrappingCompactionStrategy.java:88)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:250)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_74]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_74]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_74]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_74]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_74]
> ERROR [CompactionExecutor:13996] 2016-05-26 21:21:46,702 
> CassandraDaemon.java:185 - Exception in thread 
> Thread[CompactionExecutor:13996,1,main]
> java.lang.AssertionError: Memory was freed
> at 
> org.apache.cassandra.io.util.SafeMemory.checkBounds(SafeMemory.java:103) 
> ~[apache-cassandra-2.2.5.jar:2.2.5]
> at org.apache.cassandra.io.util.Memory.getInt(Memory.java:292) 
> ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.IndexSummary.getPositionInSummary(IndexSummary.java:148)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.IndexSummary.fillTemporaryKey(IndexSummary.java:162)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.IndexSummary.binarySearch(IndexSummary.java:121)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.getSampleIndexesForRanges(SSTableReader.java:1398)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.estimatedKeysForRanges(SSTableReader.java:1354)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionStrategy.worthDroppingTombstones(AbstractCompactionStrategy.java:403)
>  ~[apache-cassandra-2.2.5.jar:2.2.5]
> at 

[jira] [Created] (CASSANDRA-12125) ERROR [MemtableFlushWriter:4] 2016-07-01 06:20:41,137 CassandraDaemon.java:185 - Exception in thread Thread[MemtableFlushWriter:4,5,main] java.lang.RuntimeException

[Relish Chackochan (JIRA)]

Relish Chackochan created CASSANDRA-12125:
-

 Summary: ERROR [MemtableFlushWriter:4] 2016-07-01 06:20:41,137 
CassandraDaemon.java:185 - Exception in thread 
Thread[MemtableFlushWriter:4,5,main]  java.lang.RuntimeException: Last written 
key DecoratedKey(.XX, X) >= current key DecoratedKey
 Key: CASSANDRA-12125
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12125
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: RHEL-6.5 64-bit Apache Cassandra 2.2.5v
Reporter: Relish Chackochan


We are running on RHEL-6.5 64-bit with Apache Cassandra 2.2.5v on 4 node 
cluster and getting the following error on multiple node while running the 
repair job and when getting the error repair job is hang.

Can some one help to identify the issue.

ERROR [MemtableFlushWriter:4] 2016-07-01 06:20:41,137 CassandraDaemon.java:185 
- Exception in thread Thread[MemtableFlushWriter:4,5,main]
java.lang.RuntimeException: Last written key DecoratedKey(1467371986.8870, 
313436373337313938362e38383730) >= current key DecoratedKey(, 
313436373337323030312e38383730) writing into 
/opt/cassandra/data/proddb/log_data1-0a5092a0a4fa11e5872fc1ce0a46dc27/.maxdatetimeindex_idx/tmp-la-470-big-Data.db



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

[jira] [Commented] (CASSANDRA-12057) dtest failure in repair_tests.repair_test.TestRepair.repair_after_upgrade_test

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-12057:
-

[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunkcopy-dtest/19/]
 and 
[multiplexer|https://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/157/]
 runs look good. 

Submitted [dtest PR|https://github.com/riptano/cassandra-dtest/pull/1073] for 
review. No C* code change was necessary.

> dtest failure in repair_tests.repair_test.TestRepair.repair_after_upgrade_test
> --
>
> Key: CASSANDRA-12057
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12057
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Paulo Motta
>  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_dtest/1279/testReport/repair_tests.repair_test/TestRepair/repair_after_upgrade_test
> Failed on CassCI build trunk_dtest #1279
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools.py", line 288, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 217, in repair_after_upgrade_test
> self._repair_and_verify(True)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 287, in _repair_and_verify
> self.check_rows_on_node(node3, 2000, missings=[1000])
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 70, in check_rows_on_node
> self.assertEqual(len(result), rows)
>   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)
> '2001 != 2000
> {code}
> Logs are attached.



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

[jira] [Updated] (CASSANDRA-12057) dtest failure in repair_tests.repair_test.TestRepair.repair_after_upgrade_test

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-12057:

Status: Patch Available  (was: Open)

> dtest failure in repair_tests.repair_test.TestRepair.repair_after_upgrade_test
> --
>
> Key: CASSANDRA-12057
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12057
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Paulo Motta
>  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_dtest/1279/testReport/repair_tests.repair_test/TestRepair/repair_after_upgrade_test
> Failed on CassCI build trunk_dtest #1279
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools.py", line 288, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 217, in repair_after_upgrade_test
> self._repair_and_verify(True)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 287, in _repair_and_verify
> self.check_rows_on_node(node3, 2000, missings=[1000])
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 70, in check_rows_on_node
> self.assertEqual(len(result), rows)
>   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)
> '2001 != 2000
> {code}
> Logs are attached.



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

[jira] [Commented] (CASSANDRA-10988) isInclusive and boundsAsComposites in Restriction take bounds in different order

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-10988:
-

The issue was not reproducible on {{2.1}}. The tests are passing. Problem was 
related to bounds being taken in different order on different stages of query, 
because of {{EOCs}}, which seems not be the case on 2.1. 

> isInclusive and boundsAsComposites in Restriction take bounds in different 
> order
> 
>
> Key: CASSANDRA-10988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10988
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Vassil Hristov
>Assignee: Alex Petrov
> Fix For: 2.2.x
>
>
> After we've upgraded our cluster to version 2.1.11, we started getting the 
> bellow exceptions for some of our queries. Issue seems to be very similar to 
> CASSANDRA-7284.
> Code to reproduce:
> {code:java}
> createTable("CREATE TABLE %s (" +
> "a text," +
> "b int," +
> "PRIMARY KEY (a, b)" +
> ") WITH COMPACT STORAGE" +
> "AND CLUSTERING ORDER BY (b DESC)");
> execute("insert into %s (a, b) values ('a', 2)");
> execute("SELECT * FROM %s WHERE a = 'a' AND b > 0");
> {code}
> {code:java}
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.Composites$EmptyComposite cannot be cast 
> to org.apache.cassandra.db.composites.CellName
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.composites.AbstractSimpleCellNameType.makeCellName(AbstractSimpleCellNameType.java:125)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType.makeCellName(AbstractCellNameType.java:254)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeExclusiveSliceBound(SelectStatement.java:1197)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.applySliceRestriction(SelectStatement.java:1205)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1283)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1250)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:299)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:276)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:67)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:493)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
>  [apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
>  [apache-cassandra-2.1.11.jar:2.1.11]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_66]
> at 
> 

[jira] [Commented] (CASSANDRA-11850) cannot use cql since upgrading python to 2.7.11+

[Brice Dutheil (JIRA)]

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

Brice Dutheil commented on CASSANDRA-11850:
---

For reference the issue mentionned here is also present on version 2.x of 
cassandra. I just upgraded my python environment to 2.7.12 for other reasons. 
And {{cqlsh}} fails to connect with the same error :

{code}
$ cqlsh
Connection error: ('Unable to connect to any servers', {'127.0.0.1': 
TypeError('ref() does not take keyword arguments',)})
{code}

{code}
$ uname -a
Darwin ulysse 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 
2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
$ python --version
Python 2.7.12
$ cassandra -v
2.1.13
$ cqlsh --version
cqlsh 5.0.1
{code}

> cannot use cql since upgrading python to 2.7.11+
> 
>
> Key: CASSANDRA-11850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11850
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Development
>Reporter: Andrew Madison
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 3.0.x, 3.x
>
>
> OS: Debian GNU/Linux stretch/sid 
> Kernel: 4.5.0-2-amd64 #1 SMP Debian 4.5.4-1 (2016-05-16) x86_64 GNU/Linux
> Python version: 2.7.11+ (default, May  9 2016, 15:54:33)
> [GCC 5.3.1 20160429]
> cqlsh --version: cqlsh 5.0.1
> cassandra -v: 3.5 (also occurs with 3.0.6)
> Issue:
> when running cqlsh, it returns the following error:
> cqlsh -u dbarpt_usr01
> Password: *
> Connection error: ('Unable to connect to any servers', {'odbasandbox1': 
> TypeError('ref() does not take keyword arguments',)})
> I cleared PYTHONPATH:
> python -c "import json; print dir(json); print json.__version__"
> ['JSONDecoder', 'JSONEncoder', '__all__', '__author__', '__builtins__', 
> '__doc__', '__file__', '__name__', '__package__', '__path__', '__version__', 
> '_default_decoder', '_default_encoder', 'decoder', 'dump', 'dumps', 
> 'encoder', 'load', 'loads', 'scanner']
> 2.0.9
> Java based clients can connect to Cassandra with no issue. Just CQLSH and 
> Python clients cannot.
> nodetool status also works.
> Thank you for your help.



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

[jira] [Commented] (CASSANDRA-12075) Include whether or not the client should retry the request when throwing a RequestExecutionException

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-12075:
--

bq. The only thing is that if we add an exception which we dont want good 
drivers to not retry, we also need to patch the driver right away for this to 
work.

Well, you have to change the native protocol to add any exception and that 
require a driver change anyway. 

> Include whether or not the client should retry the request when throwing a 
> RequestExecutionException
> 
>
> Key: CASSANDRA-12075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12075
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Geoffrey Yu
>Assignee: Geoffrey Yu
>Priority: Minor
>
> Some requests that result in an error should not be retried by the client. 
> Right now if the client gets an error, it has no way of knowing whether or 
> not it should retry. We can include an extra field in each 
> {{RequestExecutionException}} that will indicate whether the client should 
> retry, retry on a different host, or not retry at all.



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

[jira] [Commented] (CASSANDRA-11844) Create compaction-stress

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-11844:
-

Seems it does not split the ranges properly over the data directories when 
writing currently, we probably need to use {{RangeAwareSSTableWriter}} in 
{{AbstractSSTableSimpleWriter}} (it is imported, but not used)

> Create compaction-stress
> 
>
> Key: CASSANDRA-11844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11844
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Compaction, Tools
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
> Fix For: 3.x
>
>
> A tool like cassandra-stress that works with stress yaml but:
>   * writes directly to a specified dir using CQLSSTableWriter. 
>   * lets you run just compaction on that directory and generates a report on 
> compaction throughput.



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

[jira] [Commented] (CASSANDRA-12100) Compactions are stuck after TRUNCATE

[Stefano Ortolani (JIRA)]

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

Stefano Ortolani commented on CASSANDRA-12100:
--

I've tried it but no change whatsoever.
Ended up restarting the node :/

> Compactions are stuck after TRUNCATE
> 
>
> Key: CASSANDRA-12100
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12100
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Stefano Ortolani
> Fix For: 3.0.x
>
> Attachments: node3_jstack.log
>
>
> Hi,
> since the upgrade to C* 3.0.7 I see compaction tasks getting stuck when 
> truncating the column family. I verified this on all nodes of the cluster.
> Pending compactions seem to disappear after restarting the node.
> {noformat}
> root@node10:~# nodetool -h localhost compactionstats
> pending tasks: 6
>  id   compaction type  
> keyspacetable   completed  totalunit   progress
>24e1ad30-3cac-11e6-870d-5de740693258Compaction  
> schema  table_1   0   57558382   bytes  0.00%
>2be2e3b0-3cac-11e6-870d-5de740693258Compaction  
> schema  table_2   0   65063705   bytes  0.00%
>54de38f0-3cac-11e6-870d-5de740693258Compaction  
> schema  table_3   0 187031   bytes  0.00%
>31926ce0-3cac-11e6-870d-5de740693258Compaction  
> schema  table_4   0   42951119   bytes  0.00%
>3911ad00-3cac-11e6-870d-5de740693258Compaction  
> schema  table_5   0   25918949   bytes  0.00%
>3e6a8ab0-3cac-11e6-870d-5de740693258Compaction  
> schema  table_6   0   65466210   bytes  0.00%
> Active compaction remaining time :   0h00m15s
> {noformat}



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

[jira] [Commented] (CASSANDRA-12035) Structure for tpstats output (JSON, YAML)

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-12035:
-

[~hnishi] thank you so much!

> Structure for tpstats output (JSON, YAML)
> -
>
> Key: CASSANDRA-12035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12035
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Hiroyuki Nishi
>Assignee: Hiroyuki Nishi
>Priority: Minor
> Attachments: CASSANDRA-12035-trunk.patch, tablestats_result.json, 
> tablestats_result.txt, tablestats_result.yaml, tpstats_result.json, 
> tpstats_result.txt, tpstats_result.yaml
>
>
> In CASSANDRA-5977, some extra output formats such as JSON and YAML were added 
> for nodetool tablestats. 
> Similarly, I would like to add the output formats in nodetool tpstats.
> Also, I tried to refactor the tablestats's code about the output formats to 
> integrate the existing code with my code.
> Please review the attached patch.



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

[jira] [Reopened] (CASSANDRA-10988) isInclusive and boundsAsComposites in Restriction take bounds in different order

[Alex Petrov (JIRA)]

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

Alex Petrov reopened CASSANDRA-10988:
-
Reproduced In: 2.1.14

> isInclusive and boundsAsComposites in Restriction take bounds in different 
> order
> 
>
> Key: CASSANDRA-10988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10988
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Vassil Hristov
>Assignee: Alex Petrov
> Fix For: 2.2.x
>
>
> After we've upgraded our cluster to version 2.1.11, we started getting the 
> bellow exceptions for some of our queries. Issue seems to be very similar to 
> CASSANDRA-7284.
> Code to reproduce:
> {code:java}
> createTable("CREATE TABLE %s (" +
> "a text," +
> "b int," +
> "PRIMARY KEY (a, b)" +
> ") WITH COMPACT STORAGE" +
> "AND CLUSTERING ORDER BY (b DESC)");
> execute("insert into %s (a, b) values ('a', 2)");
> execute("SELECT * FROM %s WHERE a = 'a' AND b > 0");
> {code}
> {code:java}
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.Composites$EmptyComposite cannot be cast 
> to org.apache.cassandra.db.composites.CellName
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.composites.AbstractSimpleCellNameType.makeCellName(AbstractSimpleCellNameType.java:125)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType.makeCellName(AbstractCellNameType.java:254)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeExclusiveSliceBound(SelectStatement.java:1197)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.applySliceRestriction(SelectStatement.java:1205)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1283)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1250)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:299)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:276)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:67)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:493)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
>  [apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
>  [apache-cassandra-2.1.11.jar:2.1.11]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_66]
> at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
>  [apache-cassandra-2.1.11.jar:2.1.11]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-2.1.11.jar:2.1.11]
> at java.lang.Thread.run(Thread.java:745) 

[jira] [Commented] (CASSANDRA-12035) Structure for tpstats output (JSON, YAML)

[Hiroyuki Nishi (JIRA)]

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

Hiroyuki Nishi commented on CASSANDRA-12035:


Hi [~ifesdjeen],

Thanks for your response.
 
I tried to re-create the patch with latest trunk. 
Please check the patch once again.

> Structure for tpstats output (JSON, YAML)
> -
>
> Key: CASSANDRA-12035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12035
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Hiroyuki Nishi
>Assignee: Hiroyuki Nishi
>Priority: Minor
> Attachments: CASSANDRA-12035-trunk.patch, tablestats_result.json, 
> tablestats_result.txt, tablestats_result.yaml, tpstats_result.json, 
> tpstats_result.txt, tpstats_result.yaml
>
>
> In CASSANDRA-5977, some extra output formats such as JSON and YAML were added 
> for nodetool tablestats. 
> Similarly, I would like to add the output formats in nodetool tpstats.
> Also, I tried to refactor the tablestats's code about the output formats to 
> integrate the existing code with my code.
> Please review the attached patch.



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

[jira] [Updated] (CASSANDRA-12035) Structure for tpstats output (JSON, YAML)

[Hiroyuki Nishi (JIRA)]

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

Hiroyuki Nishi updated CASSANDRA-12035:
---
Attachment: tpstats_result.yaml
tpstats_result.txt
tpstats_result.json
tablestats_result.yaml
tablestats_result.txt
tablestats_result.json
CASSANDRA-12035-trunk.patch

> Structure for tpstats output (JSON, YAML)
> -
>
> Key: CASSANDRA-12035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12035
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Hiroyuki Nishi
>Assignee: Hiroyuki Nishi
>Priority: Minor
> Attachments: CASSANDRA-12035-trunk.patch, tablestats_result.json, 
> tablestats_result.txt, tablestats_result.yaml, tpstats_result.json, 
> tpstats_result.txt, tpstats_result.yaml
>
>
> In CASSANDRA-5977, some extra output formats such as JSON and YAML were added 
> for nodetool tablestats. 
> Similarly, I would like to add the output formats in nodetool tpstats.
> Also, I tried to refactor the tablestats's code about the output formats to 
> integrate the existing code with my code.
> Please review the attached patch.



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

[jira] [Updated] (CASSANDRA-12035) Structure for tpstats output (JSON, YAML)

[Hiroyuki Nishi (JIRA)]

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

Hiroyuki Nishi updated CASSANDRA-12035:
---
Attachment: (was: tablestats_sample_result.yaml)

> Structure for tpstats output (JSON, YAML)
> -
>
> Key: CASSANDRA-12035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12035
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Hiroyuki Nishi
>Assignee: Hiroyuki Nishi
>Priority: Minor
>
> In CASSANDRA-5977, some extra output formats such as JSON and YAML were added 
> for nodetool tablestats. 
> Similarly, I would like to add the output formats in nodetool tpstats.
> Also, I tried to refactor the tablestats's code about the output formats to 
> integrate the existing code with my code.
> Please review the attached patch.



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

[jira] [Updated] (CASSANDRA-12035) Structure for tpstats output (JSON, YAML)

[Hiroyuki Nishi (JIRA)]

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

Hiroyuki Nishi updated CASSANDRA-12035:
---
Attachment: (was: tpstats_sample_result.txt)

> Structure for tpstats output (JSON, YAML)
> -
>
> Key: CASSANDRA-12035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12035
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Hiroyuki Nishi
>Assignee: Hiroyuki Nishi
>Priority: Minor
>
> In CASSANDRA-5977, some extra output formats such as JSON and YAML were added 
> for nodetool tablestats. 
> Similarly, I would like to add the output formats in nodetool tpstats.
> Also, I tried to refactor the tablestats's code about the output formats to 
> integrate the existing code with my code.
> Please review the attached patch.



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

[jira] [Updated] (CASSANDRA-12035) Structure for tpstats output (JSON, YAML)

[Hiroyuki Nishi (JIRA)]

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

Hiroyuki Nishi updated CASSANDRA-12035:
---
Attachment: (was: tpstats_sample_result.json)

> Structure for tpstats output (JSON, YAML)
> -
>
> Key: CASSANDRA-12035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12035
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Hiroyuki Nishi
>Assignee: Hiroyuki Nishi
>Priority: Minor
>
> In CASSANDRA-5977, some extra output formats such as JSON and YAML were added 
> for nodetool tablestats. 
> Similarly, I would like to add the output formats in nodetool tpstats.
> Also, I tried to refactor the tablestats's code about the output formats to 
> integrate the existing code with my code.
> Please review the attached patch.



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

[jira] [Updated] (CASSANDRA-12035) Structure for tpstats output (JSON, YAML)

[Hiroyuki Nishi (JIRA)]

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

Hiroyuki Nishi updated CASSANDRA-12035:
---
Attachment: (was: tablestats_sample_result.json)

> Structure for tpstats output (JSON, YAML)
> -
>
> Key: CASSANDRA-12035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12035
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Hiroyuki Nishi
>Assignee: Hiroyuki Nishi
>Priority: Minor
>
> In CASSANDRA-5977, some extra output formats such as JSON and YAML were added 
> for nodetool tablestats. 
> Similarly, I would like to add the output formats in nodetool tpstats.
> Also, I tried to refactor the tablestats's code about the output formats to 
> integrate the existing code with my code.
> Please review the attached patch.



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

[jira] [Updated] (CASSANDRA-12035) Structure for tpstats output (JSON, YAML)

[Hiroyuki Nishi (JIRA)]

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

Hiroyuki Nishi updated CASSANDRA-12035:
---
Attachment: (was: tablestats_sample_result.txt)

> Structure for tpstats output (JSON, YAML)
> -
>
> Key: CASSANDRA-12035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12035
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Hiroyuki Nishi
>Assignee: Hiroyuki Nishi
>Priority: Minor
>
> In CASSANDRA-5977, some extra output formats such as JSON and YAML were added 
> for nodetool tablestats. 
> Similarly, I would like to add the output formats in nodetool tpstats.
> Also, I tried to refactor the tablestats's code about the output formats to 
> integrate the existing code with my code.
> Please review the attached patch.



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

[jira] [Updated] (CASSANDRA-12035) Structure for tpstats output (JSON, YAML)

[Hiroyuki Nishi (JIRA)]

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

Hiroyuki Nishi updated CASSANDRA-12035:
---
Attachment: (was: tpstats_sample_result.yaml)

> Structure for tpstats output (JSON, YAML)
> -
>
> Key: CASSANDRA-12035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12035
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Hiroyuki Nishi
>Assignee: Hiroyuki Nishi
>Priority: Minor
>
> In CASSANDRA-5977, some extra output formats such as JSON and YAML were added 
> for nodetool tablestats. 
> Similarly, I would like to add the output formats in nodetool tpstats.
> Also, I tried to refactor the tablestats's code about the output formats to 
> integrate the existing code with my code.
> Please review the attached patch.



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

[jira] [Updated] (CASSANDRA-12035) Structure for tpstats output (JSON, YAML)

[Hiroyuki Nishi (JIRA)]

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

Hiroyuki Nishi updated CASSANDRA-12035:
---
Attachment: (was: CASSANDRA-12035-trunk.patch)

> Structure for tpstats output (JSON, YAML)
> -
>
> Key: CASSANDRA-12035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12035
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Hiroyuki Nishi
>Assignee: Hiroyuki Nishi
>Priority: Minor
> Attachments: tablestats_sample_result.json, 
> tablestats_sample_result.txt, tablestats_sample_result.yaml, 
> tpstats_sample_result.json, tpstats_sample_result.txt, 
> tpstats_sample_result.yaml
>
>
> In CASSANDRA-5977, some extra output formats such as JSON and YAML were added 
> for nodetool tablestats. 
> Similarly, I would like to add the output formats in nodetool tpstats.
> Also, I tried to refactor the tablestats's code about the output formats to 
> integrate the existing code with my code.
> Please review the attached patch.



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

[jira] [Commented] (CASSANDRA-10988) isInclusive and boundsAsComposites in Restriction take bounds in different order

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-10988:


[~kohlisankalp] It was decided since some time to only push fixes for critical 
issues to 2.1. The problem becoming do decide what is a critical issue and what 
is not.
In this case, the description is suggesting that the problem is a new one but 
the location of the problem made us believe that the issue had always been 
there. By consequence, it was arguable that the problem was a critical one. I 
concluded, like Alex probably did, that the issue might not be really critical.
Looking at it now, I agree that we should probably have provided a patch for 
2.1. 
Are you also facing the same issue?

> isInclusive and boundsAsComposites in Restriction take bounds in different 
> order
> 
>
> Key: CASSANDRA-10988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10988
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Vassil Hristov
>Assignee: Alex Petrov
> Fix For: 2.2.x
>
>
> After we've upgraded our cluster to version 2.1.11, we started getting the 
> bellow exceptions for some of our queries. Issue seems to be very similar to 
> CASSANDRA-7284.
> Code to reproduce:
> {code:java}
> createTable("CREATE TABLE %s (" +
> "a text," +
> "b int," +
> "PRIMARY KEY (a, b)" +
> ") WITH COMPACT STORAGE" +
> "AND CLUSTERING ORDER BY (b DESC)");
> execute("insert into %s (a, b) values ('a', 2)");
> execute("SELECT * FROM %s WHERE a = 'a' AND b > 0");
> {code}
> {code:java}
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.Composites$EmptyComposite cannot be cast 
> to org.apache.cassandra.db.composites.CellName
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.composites.AbstractSimpleCellNameType.makeCellName(AbstractSimpleCellNameType.java:125)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType.makeCellName(AbstractCellNameType.java:254)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.makeExclusiveSliceBound(SelectStatement.java:1197)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.applySliceRestriction(SelectStatement.java:1205)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1283)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1250)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:299)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:276)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:67)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:493)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
>  [apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
>  [apache-cassandra-2.1.11.jar:2.1.11]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
>  

[jira] [Commented] (CASSANDRA-11638) Add cassandra-stress test source

[Christopher Batey (JIRA)]

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

Christopher Batey commented on CASSANDRA-11638:
---

looks good, thanks [~jkni]

> Add cassandra-stress test source
> 
>
> Key: CASSANDRA-11638
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11638
> Project: Cassandra
>  Issue Type: Test
>  Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Minor
>  Labels: stress
> Fix For: 3.x
>
> Attachments: 
> 0001-Add-a-test-source-directory-for-Cassandra-stress.patch
>
>
> This adds a test root for cassandra-stress and a couple of noddy tests for a 
> jira I did last week to prove it works / fails the build if they fail.
> I put the source in {{tools/stress/test/unit}} and the classes in 
> {{build/test/stress-classes}} (rather than putting them in with the main test 
> classes).
> Patch attached or at: https://github.com/chbatey/cassandra-1/tree/stress-tests



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