[jira] [Commented] (CASSANDRA-10908) bad report: client_encryption seems to prevent startup in 2.2.4 and 3.1

2017-01-31 Thread Manoj (JIRA) 

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

Manoj commented on CASSANDRA-10908:
---

[~yukim] - these are the version info's:


[cqlsh 4.1.1 | Cassandra 2.0.12.274 | DSE 4.6.2 
| CQL spec 3.1.1 | Thrift protocol 19.39.0]

> bad report: client_encryption seems to prevent startup in 2.2.4 and 3.1
> ---
>
> Key: CASSANDRA-10908
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10908
> Project: Cassandra
>  Issue Type: Bug
> Environment: Amazon Linux 2015.09
>Reporter: Will Hayworth
> Attachments: 2.2.4-client-log-trace.log, client_encryption.log
>
>
> Hi there! I'm a total Cassandra novice, so please forgive me if this report 
> is lacking or malformed. I've been setting up a new cluster and trying to use 
> 3.1 but I've noticed that so much as *enabling* client-to-node encryption 
> causes the node to shut down after determining there's no gossip backlog. 
> Notably, I set up node-to-node encryption beforehand and that was working 
> just fine. I thought they might be interfering with each other, but that 
> seems not to be the case. Logs attached. (Please let me know how I can be of 
> further help!)
> Thanks for looking at this,
> Will



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-10908) bad report: client_encryption seems to prevent startup in 2.2.4 and 3.1

2017-01-31 Thread Manoj (JIRA) 

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

Manoj commented on CASSANDRA-10908:
---

[~yukim] - Hi [~yukim], I am getting same exception/error after enabling client 
encryption. May i know how to resolve/get away from the exception. Please let 
me know can i copy the logs here??




> bad report: client_encryption seems to prevent startup in 2.2.4 and 3.1
> ---
>
> Key: CASSANDRA-10908
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10908
> Project: Cassandra
>  Issue Type: Bug
> Environment: Amazon Linux 2015.09
>Reporter: Will Hayworth
> Attachments: 2.2.4-client-log-trace.log, client_encryption.log
>
>
> Hi there! I'm a total Cassandra novice, so please forgive me if this report 
> is lacking or malformed. I've been setting up a new cluster and trying to use 
> 3.1 but I've noticed that so much as *enabling* client-to-node encryption 
> causes the node to shut down after determining there's no gossip backlog. 
> Notably, I set up node-to-node encryption beforehand and that was working 
> just fine. I thought they might be interfering with each other, but that 
> seems not to be the case. Logs attached. (Please let me know how I can be of 
> further help!)
> Thanks for looking at this,
> Will



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13174) Indexing is allowed on Duration type when it should not be

2017-01-31 Thread Kishan Karunaratne (JIRA) 

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

Kishan Karunaratne updated CASSANDRA-13174:
---
Description: 
Looks like secondary indexing is allowed on duration type columns. Since 
comparisons are not possible for the duration type, indexing on it also should 
be invalid.

1) 
{noformat}
CREATE TABLE duration_table (k int PRIMARY KEY, d duration);
INSERT INTO duration_table (k, d) VALUES (0, 1s);
SELECT * from duration_table WHERE d=1s ALLOW FILTERING;
{noformat}

The above throws an error: 
{noformat}
WARN  [ReadStage-2] 2017-01-31 17:09:57,821 
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
Thread[ReadStage-2,10,main]: {}
java.lang.RuntimeException: java.lang.UnsupportedOperationException
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2591)
 ~[main/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_91]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
 ~[main/:na]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
 [main/:na]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
Caused by: java.lang.UnsupportedOperationException: null
at 
org.apache.cassandra.db.marshal.AbstractType.compareCustom(AbstractType.java:174)
 ~[main/:na]
at 
org.apache.cassandra.db.marshal.AbstractType.compare(AbstractType.java:160) 
~[main/:na]
at 
org.apache.cassandra.db.marshal.AbstractType.compareForCQL(AbstractType.java:204)
 ~[main/:na]
at org.apache.cassandra.cql3.Operator.isSatisfiedBy(Operator.java:201) 
~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$SimpleExpression.isSatisfiedBy(RowFilter.java:719)
 ~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToRow(RowFilter.java:324)
 ~[main/:na]
at 
org.apache.cassandra.db.transform.BaseRows.applyOne(BaseRows.java:120) 
~[main/:na]
at org.apache.cassandra.db.transform.BaseRows.add(BaseRows.java:110) 
~[main/:na]
at 
org.apache.cassandra.db.transform.UnfilteredRows.add(UnfilteredRows.java:44) 
~[main/:na]
at 
org.apache.cassandra.db.transform.Transformation.add(Transformation.java:174) 
~[main/:na]
at 
org.apache.cassandra.db.transform.Transformation.apply(Transformation.java:140) 
~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:307)
 ~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:292)
 ~[main/:na]
at 
org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
 ~[main/:na]
at 
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:310)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76) 
~[main/:na]
at 
org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:333) 
~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1884)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2587)
 ~[main/:na]
... 5 common frames omitted
{noformat}

2)
Similarly, if an index is created on the duration column:
{noformat}
CREATE INDEX d_index ON simplex.duration_table (d);
SELECT * from duration_table WHERE d=1s;
{noformat}

results in:
{noformat}
WARN  [ReadStage-2] 2017-01-31 17:12:00,623 
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
Thread[ReadStage-2,10,main]: {}
java.lang.RuntimeException: 
org.apache.cassandra.index.IndexNotAvailableException: The secondary index 
'd_index' is not yet available
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2591)
 ~[main/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_91]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
 ~[main/:na]
at

[jira] [Updated] (CASSANDRA-13174) Indexing is allowed on Duration type when it should not be

2017-01-31 Thread Kishan Karunaratne (JIRA) 

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

Kishan Karunaratne updated CASSANDRA-13174:
---
Description: 
Looks like secondary indexing is allowed on duration type columns. Since 
comparisons are not possible for the duration type, indexing on it also should 
be invalid.

1) 
{noformat}
CREATE TABLE duration_table (k int PRIMARY KEY, d duration);
INSERT INTO duration_table (k, d) VALUES (0, 1s);
SELECT * from duration_table WHERE d=1s ALLOW FILTERING;
{noformat}

The above throws an error: 
{noformat}
WARN  [ReadStage-2] 2017-01-31 17:09:57,821 
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
Thread[ReadStage-2,10,main]: {}
java.lang.RuntimeException: java.lang.UnsupportedOperationException
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2591)
 ~[main/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_91]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
 ~[main/:na]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
 [main/:na]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
Caused by: java.lang.UnsupportedOperationException: null
at 
org.apache.cassandra.db.marshal.AbstractType.compareCustom(AbstractType.java:174)
 ~[main/:na]
at 
org.apache.cassandra.db.marshal.AbstractType.compare(AbstractType.java:160) 
~[main/:na]
at 
org.apache.cassandra.db.marshal.AbstractType.compareForCQL(AbstractType.java:204)
 ~[main/:na]
at org.apache.cassandra.cql3.Operator.isSatisfiedBy(Operator.java:201) 
~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$SimpleExpression.isSatisfiedBy(RowFilter.java:719)
 ~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToRow(RowFilter.java:324)
 ~[main/:na]
at 
org.apache.cassandra.db.transform.BaseRows.applyOne(BaseRows.java:120) 
~[main/:na]
at org.apache.cassandra.db.transform.BaseRows.add(BaseRows.java:110) 
~[main/:na]
at 
org.apache.cassandra.db.transform.UnfilteredRows.add(UnfilteredRows.java:44) 
~[main/:na]
at 
org.apache.cassandra.db.transform.Transformation.add(Transformation.java:174) 
~[main/:na]
at 
org.apache.cassandra.db.transform.Transformation.apply(Transformation.java:140) 
~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:307)
 ~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:292)
 ~[main/:na]
at 
org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
 ~[main/:na]
at 
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:310)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76) 
~[main/:na]
at 
org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:333) 
~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1884)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2587)
 ~[main/:na]
... 5 common frames omitted
{noformat}

2)
Similarly, if an index is created on the duration column:
{noformat}
CREATE INDEX d_index ON simplex.duration_table (d);
SELECT * from duration_table WHERE d=1s;
{noformat}

results in:
{noformat}
WARN  [ReadStage-2] 2017-01-31 17:12:00,623 
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
Thread[ReadStage-2,10,main]: {}
java.lang.RuntimeException: 
org.apache.cassandra.index.IndexNotAvailableException: The secondary index 
'd_index' is not yet available
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2591)
 ~[main/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_91]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
 ~[main/:na]
at

[jira] [Updated] (CASSANDRA-13174) Indexing is allowed on Duration type when it should not be

2017-01-31 Thread Kishan Karunaratne (JIRA) 

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

Kishan Karunaratne updated CASSANDRA-13174:
---
Reproduced In: 3.10

> Indexing is allowed on Duration type when it should not be
> --
>
> Key: CASSANDRA-13174
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13174
> Project: Cassandra
>  Issue Type: Bug
> Environment: C* 3.10
>Reporter: Kishan Karunaratne
>
> Looks like secondary indexing is allowed on duration type columns. Since 
> comparisons are not possible for the duration type, indexing on it also 
> should be invalid.
> 1) 
> {noformat}
> CREATE TABLE simplex.duration_table (k int PRIMARY KEY, d duration);
> INSERT INTO duration_table (k, d) VALUES (0, 1s);
> SELECT * from duration_table WHERE d=1s ALLOW FILTERING;
> {noformat}
> The above throws an error: 
> {noformat}
> WARN  [ReadStage-2] 2017-01-31 17:09:57,821 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-2,10,main]: {}
> java.lang.RuntimeException: java.lang.UnsupportedOperationException
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2591)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_91]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  ~[main/:na]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
>  [main/:na]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [main/:na]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> Caused by: java.lang.UnsupportedOperationException: null
>   at 
> org.apache.cassandra.db.marshal.AbstractType.compareCustom(AbstractType.java:174)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.marshal.AbstractType.compare(AbstractType.java:160) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.marshal.AbstractType.compareForCQL(AbstractType.java:204)
>  ~[main/:na]
>   at org.apache.cassandra.cql3.Operator.isSatisfiedBy(Operator.java:201) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.filter.RowFilter$SimpleExpression.isSatisfiedBy(RowFilter.java:719)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToRow(RowFilter.java:324)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.BaseRows.applyOne(BaseRows.java:120) 
> ~[main/:na]
>   at org.apache.cassandra.db.transform.BaseRows.add(BaseRows.java:110) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.UnfilteredRows.add(UnfilteredRows.java:44) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.Transformation.add(Transformation.java:174) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.Transformation.apply(Transformation.java:140)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:307)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:292)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:310)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:333) 
> ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1884)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2587)
>  ~[main/:na]
>   ... 5 common frames omitted
> {noformat}
> 2)
> Similarly, if an index is created on the duration column:
> {noformat}
> CREATE INDEX d_index ON simplex.duration_table (d);
> SELECT * from duration_table WHERE d=1s;
> {noformat}
> results in:
> {noformat}
> WARN  [ReadStage-2] 2017-01-31 17:12:00,623 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-2,10,main]: {}
> java.lang.RuntimeException: 
>

[jira] [Updated] (CASSANDRA-13174) Indexing is allowed on Duration type when it should not be

2017-01-31 Thread Kishan Karunaratne (JIRA) 

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

Kishan Karunaratne updated CASSANDRA-13174:
---
Description: 
Looks like secondary indexing is allowed on duration type columns. Since 
comparisons are not possible for the duration type, indexing on it also should 
be invalid.

1) 
{noformat}
CREATE TABLE simplex.duration_table (k int PRIMARY KEY, d duration);
INSERT INTO duration_table (k, d) VALUES (0, 1s);
SELECT * from duration_table WHERE d=1s ALLOW FILTERING;
{noformat}

The above throws an error: 
{noformat}
WARN  [ReadStage-2] 2017-01-31 17:09:57,821 
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
Thread[ReadStage-2,10,main]: {}
java.lang.RuntimeException: java.lang.UnsupportedOperationException
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2591)
 ~[main/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_91]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
 ~[main/:na]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
 [main/:na]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
Caused by: java.lang.UnsupportedOperationException: null
at 
org.apache.cassandra.db.marshal.AbstractType.compareCustom(AbstractType.java:174)
 ~[main/:na]
at 
org.apache.cassandra.db.marshal.AbstractType.compare(AbstractType.java:160) 
~[main/:na]
at 
org.apache.cassandra.db.marshal.AbstractType.compareForCQL(AbstractType.java:204)
 ~[main/:na]
at org.apache.cassandra.cql3.Operator.isSatisfiedBy(Operator.java:201) 
~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$SimpleExpression.isSatisfiedBy(RowFilter.java:719)
 ~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToRow(RowFilter.java:324)
 ~[main/:na]
at 
org.apache.cassandra.db.transform.BaseRows.applyOne(BaseRows.java:120) 
~[main/:na]
at org.apache.cassandra.db.transform.BaseRows.add(BaseRows.java:110) 
~[main/:na]
at 
org.apache.cassandra.db.transform.UnfilteredRows.add(UnfilteredRows.java:44) 
~[main/:na]
at 
org.apache.cassandra.db.transform.Transformation.add(Transformation.java:174) 
~[main/:na]
at 
org.apache.cassandra.db.transform.Transformation.apply(Transformation.java:140) 
~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:307)
 ~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:292)
 ~[main/:na]
at 
org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
 ~[main/:na]
at 
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:310)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76) 
~[main/:na]
at 
org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:333) 
~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1884)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2587)
 ~[main/:na]
... 5 common frames omitted
{noformat}

2)
Similarly, if an index is created on the duration column:
{noformat}
CREATE INDEX d_index ON simplex.duration_table (d);
SELECT * from duration_table WHERE d=1s;
{noformat}

results in:
{noformat}
WARN  [ReadStage-2] 2017-01-31 17:12:00,623 
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
Thread[ReadStage-2,10,main]: {}
java.lang.RuntimeException: 
org.apache.cassandra.index.IndexNotAvailableException: The secondary index 
'd_index' is not yet available
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2591)
 ~[main/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_91]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
 ~[main/:na]
at

[jira] [Created] (CASSANDRA-13174) Indexing is allowed on Duration type when it should not be

2017-01-31 Thread Kishan Karunaratne (JIRA) 
Kishan Karunaratne created CASSANDRA-13174:
--

 Summary: Indexing is allowed on Duration type when it should not be
 Key: CASSANDRA-13174
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13174
 Project: Cassandra
  Issue Type: Bug
 Environment: C* 3.10
Reporter: Kishan Karunaratne


Looks like secondary indexing is allowed on duration type columns. Since 
comparisons are not possible for the duration type, indexing on it also should 
be invalid.

1) 
{noformat}
CREATE TABLE simplex.duration_table (k int PRIMARY KEY, d duration);
INSERT INTO duration_table (k, d) VALUES (0, 1s);
SELECT * from duration_table WHERE d=1s ALLOW FILTERING;
{noformat}

The above throws an error: 
{noformat}
WARN  [ReadStage-2] 2017-01-31 17:09:57,821 
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
Thread[ReadStage-2,10,main]: {}
java.lang.RuntimeException: java.lang.UnsupportedOperationException
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2591)
 ~[main/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_91]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
 ~[main/:na]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
 [main/:na]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
Caused by: java.lang.UnsupportedOperationException: null
at 
org.apache.cassandra.db.marshal.AbstractType.compareCustom(AbstractType.java:174)
 ~[main/:na]
at 
org.apache.cassandra.db.marshal.AbstractType.compare(AbstractType.java:160) 
~[main/:na]
at 
org.apache.cassandra.db.marshal.AbstractType.compareForCQL(AbstractType.java:204)
 ~[main/:na]
at org.apache.cassandra.cql3.Operator.isSatisfiedBy(Operator.java:201) 
~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$SimpleExpression.isSatisfiedBy(RowFilter.java:719)
 ~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToRow(RowFilter.java:324)
 ~[main/:na]
at 
org.apache.cassandra.db.transform.BaseRows.applyOne(BaseRows.java:120) 
~[main/:na]
at org.apache.cassandra.db.transform.BaseRows.add(BaseRows.java:110) 
~[main/:na]
at 
org.apache.cassandra.db.transform.UnfilteredRows.add(UnfilteredRows.java:44) 
~[main/:na]
at 
org.apache.cassandra.db.transform.Transformation.add(Transformation.java:174) 
~[main/:na]
at 
org.apache.cassandra.db.transform.Transformation.apply(Transformation.java:140) 
~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:307)
 ~[main/:na]
at 
org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:292)
 ~[main/:na]
at 
org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
 ~[main/:na]
at 
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:310)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
 ~[main/:na]
at 
org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76) 
~[main/:na]
at 
org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:333) 
~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1884)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2587)
 ~[main/:na]
... 5 common frames omitted
{noformat}

2)
Similarly, if an index is created on the duration column:
{noformat}
CREATE INDEX d_index ON simplex.duration_table (d);
SELECT * from duration_table WHERE d=1s;
{noformat}

results in:
{noformat}
WARN  [ReadStage-2] 2017-01-31 17:12:00,623 
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
Thread[ReadStage-2,10,main]: {}
java.lang.RuntimeException: 
org.apache.cassandra.index.IndexNotAvailableException: The secondary index 
'd_index' is not yet available
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2591)
 ~[main/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_91]
at

[jira] [Commented] (CASSANDRA-9989) Optimise BTree.Buider

2017-01-31 Thread Jay Zhuang (JIRA) 

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

Jay Zhuang commented on CASSANDRA-9989:
---

Thanks Benedict for the information. I agree that BTree.Builder could be 
further improved, currently it copys all the data in array and build the tree.

I did some improvements for 
[{{BTree.buildInternal()}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/btree/BTree.java#L128],
 which is used by both {{BTree.Builder}} and {{BTree.build()}}. It improves the 
{{build()}} performance by about {{+190%}}. And it benefits Builder too (about 
{{+50%}}). The 
[patch|https://github.com/cooldoger/cassandra/commit/bf6bc14a130dae64cb859e81ad54b21d5434d46a]
 is attached.

Here are the JMH benchmark test results:
|| 
[TestCode|https://github.com/cooldoger/cassandra/commit/bf6bc14a130dae64cb859e81ad54b21d5434d46a#diff-b91288be52d83bf95ac5eb819f9fe3d4]
 || Before the patch || After the patch || Performance increased: {{(after - 
before)/before}} ||
| buildLeafTreeTest | 5274.457 | 13096.541 | +148% |
| buildLeafTreeBuilderTest | 1763.279 | 2223.307 | +26% |
| build1KValuesTreeTest | 117.937 | 371.845 | +215% |
| build1KValuesTreeBuilderTest | 68.103 | 102.884 | +51% |
| build5KValuesTreeTest | 19.463 | 59.202 | +204% |
| build5KValuesTreeBuilderTest | 11.349 | 19.209 | +69% |
| build1MValuesTreeTest | 0.104 | 0.296 | +185% |
| build1MValuesTreeBuilderTest | 0.049 | 0.080 | +63% |
| transformAndFilter1KTest | 29.502 | 37.432 | +27% |
| transformAndFilter1MTest | 0.031 | 0.036 | +16% |

{{BTree.build()}} is about 1 time faster than {{BTree.Builder}}, as Builder 
copies the data and then calls {{build()}} internally 
(https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/btree/BTree.java#L1088).
 I guess that could be further improved too.

Benchmark test details:
No fix:
{noformat}
 [java] Benchmark Mode  Cnt  
Score  Error   Units
 [java] BTreeBuildBench.build1KValuesTreeBuilderTest thrpt   40 
68.103 ?2.694  ops/ms
 [java] BTreeBuildBench.build1KValuesTreeTestthrpt   40
117.937 ?   12.761  ops/ms
 [java] BTreeBuildBench.build1MValuesTreeBuilderTest thrpt   40  
0.049 ?0.002  ops/ms
 [java] BTreeBuildBench.build1MValuesTreeTestthrpt   40  
0.104 ?0.007  ops/ms
 [java] BTreeBuildBench.build5KValuesTreeBuilderTest thrpt   40 
11.349 ?0.743  ops/ms
 [java] BTreeBuildBench.build5KValuesTreeTestthrpt   40 
19.463 ?1.489  ops/ms
 [java] BTreeBuildBench.buildLeafTreeBuilderTest thrpt   40   
1763.279 ?  138.734  ops/ms
 [java] BTreeBuildBench.buildLeafTreeTestthrpt   40   
5274.457 ?  391.289  ops/ms
 [java] BTreeBuildBench.transformAndFilter1KTest thrpt   40 
29.502 ?1.548  ops/ms
 [java] BTreeBuildBench.transformAndFilter1MTest thrpt   40  
0.031 ?0.001  ops/ms
{noformat}

With Fix:
{noformat}
 [java] Benchmark Mode  Cnt  
Score  Error   Units
 [java] BTreeBuildBench.build1KValuesTreeBuilderTest thrpt   40
102.884 ?6.888  ops/ms
 [java] BTreeBuildBench.build1KValuesTreeTestthrpt   40
371.845 ?   52.153  ops/ms
 [java] BTreeBuildBench.build1MValuesTreeBuilderTest thrpt   40  
0.080 ?0.004  ops/ms
 [java] BTreeBuildBench.build1MValuesTreeTestthrpt   40  
0.296 ?0.037  ops/ms
 [java] BTreeBuildBench.build5KValuesTreeBuilderTest thrpt   40 
19.209 ?1.587  ops/ms
 [java] BTreeBuildBench.build5KValuesTreeTestthrpt   40 
59.202 ?7.439  ops/ms
 [java] BTreeBuildBench.buildLeafTreeBuilderTest thrpt   40   
2223.307 ?  179.095  ops/ms
 [java] BTreeBuildBench.buildLeafTreeTestthrpt   40  
13096.541 ? 1879.591  ops/ms
 [java] BTreeBuildBench.transformAndFilter1KTest thrpt   40 
37.432 ?2.371  ops/ms
 [java] BTreeBuildBench.transformAndFilter1MTest thrpt   40  
0.036 ?0.002  ops/ms
{noformat}

> Optimise BTree.Buider
> -
>
> Key: CASSANDRA-9989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9989
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
> Fix For: 4.x
>
> Attachments: 9989-trunk.txt
>
>
> BTree.Builder could reduce its copying, and exploit toArray more efficiently, 
> with some work. It's not very important right now because we don't make as 
> much use of its bulk-add methods as we otherwise might, however over time 
> this work will become more useful.



--
This

[jira] [Updated] (CASSANDRA-9989) Optimise BTree.Buider

2017-01-31 Thread Jay Zhuang (JIRA) 

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

Jay Zhuang updated CASSANDRA-9989:
--
Fix Version/s: (was: 3.x)
   4.x
   Status: Patch Available  (was: Open)

> Optimise BTree.Buider
> -
>
> Key: CASSANDRA-9989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9989
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
> Fix For: 4.x
>
> Attachments: 9989-trunk.txt
>
>
> BTree.Builder could reduce its copying, and exploit toArray more efficiently, 
> with some work. It's not very important right now because we don't make as 
> much use of its bulk-add methods as we otherwise might, however over time 
> this work will become more useful.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-9989) Optimise BTree.Buider

2017-01-31 Thread Jay Zhuang (JIRA) 

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

Jay Zhuang updated CASSANDRA-9989:
--
Attachment: 9989-trunk.txt

> Optimise BTree.Buider
> -
>
> Key: CASSANDRA-9989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9989
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 9989-trunk.txt
>
>
> BTree.Builder could reduce its copying, and exploit toArray more efficiently, 
> with some work. It's not very important right now because we don't make as 
> much use of its bulk-add methods as we otherwise might, however over time 
> this work will become more useful.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13173) Reloading logback.xml does not work

2017-01-31 Thread Robert Stupp (JIRA) 

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

Robert Stupp updated CASSANDRA-13173:
-
Status: Patch Available  (was: Open)

||cassandra-3.0|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...snazy:13173-logback-reload-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-13173-logback-reload-3.0-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-13173-logback-reload-3.0-dtest/lastSuccessfulBuild/]
||cassandra-3.X|[branch|https://github.com/apache/cassandra/compare/cassandra-3.X...snazy:13173-logback-reload-3.X]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-13173-logback-reload-3.X-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-13173-logback-reload-3.X-dtest/lastSuccessfulBuild/]
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:13173-logback-reload-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-13173-logback-reload-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-13173-logback-reload-trunk-dtest/lastSuccessfulBuild/]

CI triggered

> Reloading logback.xml does not work
> ---
>
> Key: CASSANDRA-13173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13173
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.0.x
>
>
> Regression of CASSANDRA-12535
> Reloading of logback.xml is broken by CASSANDRA-12535 because the delegate 
> {{ReconfigureOnChangeFilter}} is not properly initialized.
> (Broken in 3.0.11 + 3.10)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CASSANDRA-13173) Reloading logback.xml does not work

2017-01-31 Thread Robert Stupp (JIRA) 
Robert Stupp created CASSANDRA-13173:


 Summary: Reloading logback.xml does not work
 Key: CASSANDRA-13173
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13173
 Project: Cassandra
  Issue Type: Bug
Reporter: Robert Stupp
Assignee: Robert Stupp
Priority: Minor
 Fix For: 3.0.x


Regression of CASSANDRA-12535

Reloading of logback.xml is broken by CASSANDRA-12535 because the delegate 
{{ReconfigureOnChangeFilter}} is not properly initialized.
(Broken in 3.0.11 + 3.10)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-9989) Optimise BTree.Buider

2017-01-31 Thread Jay Zhuang (JIRA) 

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

Jay Zhuang reassigned CASSANDRA-9989:
-

Assignee: Jay Zhuang

> Optimise BTree.Buider
> -
>
> Key: CASSANDRA-9989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9989
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
> Fix For: 3.x
>
>
> BTree.Builder could reduce its copying, and exploit toArray more efficiently, 
> with some work. It's not very important right now because we don't make as 
> much use of its bulk-add methods as we otherwise might, however over time 
> this work will become more useful.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13156) Introduce an interface to tracing for determining whether a query should be traced

2017-01-31 Thread Sam Overton (JIRA) 

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

Sam Overton commented on CASSANDRA-13156:
-

The decision is currently made in {{QueryState.traceNextQuery}} so there is 
currently nothing to override in the tracing implementation to change this 
behavior.

> Introduce an interface to tracing for determining whether a query should be 
> traced
> --
>
> Key: CASSANDRA-13156
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13156
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Observability
>Reporter: Sam Overton
>Assignee: Sam Overton
>  Labels: ops
>
> This is a similar idea to CASSANDRA-9193 but following the same pattern that 
> we have for IAuthenticator, IEndpointSnitch, ConfigurationLoader et al. where 
> the intention is that useful default implementations are provided, but 
> abstracted in such a way that custom implementations can be written for 
> deployments where a specific type of functionality is required. This would 
> then allow solutions such as CASSANDRA-11012 without any specific support 
> needing to be written in Cassandra.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13115) Read repair is not blocking repair to finish in foreground repair

2017-01-31 Thread Michael Shuler (JIRA) 

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

Michael Shuler updated CASSANDRA-13115:
---
Fix Version/s: (was: 3.11)
   3.10

> Read repair is not blocking repair to finish in foreground repair
> -
>
> Key: CASSANDRA-13115
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13115
> Project: Cassandra
>  Issue Type: Bug
> Environment: ccm on OSX 
>Reporter: Xiaolong Jiang
>Assignee: Sylvain Lebresne
> Fix For: 3.0.11, 3.10
>
>
> The code trying to wait(block) for repair result to come back in 3.X is below:
> {code:title= DataResolver.java|borderStyle=solid}
> public void close()
> {
> try
> {
> FBUtilities.waitOnFutures(repairResults, 
> DatabaseDescriptor.getWriteRpcTimeout());
> }
> catch (TimeoutException ex)
> {
> // We got all responses, but timed out while repairing
> int blockFor = consistency.blockFor(keyspace);
> if (Tracing.isTracing())
> Tracing.trace("Timed out while read-repairing after 
> receiving all {} data and digest responses", blockFor);
> else
> logger.debug("Timeout while read-repairing after 
> receiving all {} data and digest responses", blockFor);
> throw new ReadTimeoutException(consistency, blockFor-1, 
> blockFor, true);
> }
> }
> {code}
> in DataResolver class, but this close method is never called and it's also 
> not auto close(RepairMergeListener is not extending from 
> AutoCloseable/CloseableIterator) which means we never wait for repair to 
> finish before returning final result. 
> The steps to reproduce:
> 1. create some keyspace/table with RF = 2
> 2. start 2 nodes using ccm
> 3. stop node2
> 4. disable node1 hinted hand off
> 5. write some data to node1 with consistency level one
> 6. start node2
> 7. query some data from node1 
> This should trigger read repair. I put some log in above close method, and 
> can not see log print put.
> So this bug will basically violate "monotonic quorum reads " guarantee. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13075) Indexer is not correctly invoked when building indexes over sstables

2017-01-31 Thread Michael Shuler (JIRA) 

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

Michael Shuler updated CASSANDRA-13075:
---
Fix Version/s: (was: 3.11)
   3.10

> Indexer is not correctly invoked when building indexes over sstables
> 
>
> Key: CASSANDRA-13075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13075
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sergio Bossa
>Assignee: Alex Petrov
>Priority: Critical
> Fix For: 3.0.11, 3.10, 4.0
>
> Attachments: CustomIndexTest.java
>
>
> Following CASSANDRA-12796, {{SecondaryIndexManager#indexPartition()}} calls 
> each {{Indexer}} {{begin}} and {{finish}} methods multiple times per 
> partition (depending on the page size), as 
> {{PartitionIterators#getOnlyElement()}} returns an empty partition even when 
> the iterator is exhausted.
> This leads to bugs for {{Indexer}} implementations doing actual work in those 
>  methods, but even worse, it provides the {{Indexer}} the same input of an 
> empty partition containing only a non-live partition deletion, as the 
> {{Indexer#partitionDelete()}} method is *not* actually called.
> My proposed solution:
> 1) Stop the iteration before the empty partition is returned and ingested 
> into the {{Indexer}}.
> 2) Actually call the {{Indexer#partitionDelete()}} method inside 
> {{SecondaryIndexManager#indexPartition()}} (which requires to use a filtered 
> iterator so it actually contains the deletion info).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13025) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test

2017-01-31 Thread Michael Shuler (JIRA) 

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

Michael Shuler updated CASSANDRA-13025:
---
Fix Version/s: (was: 3.11)

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x.static_columns_with_distinct_test
> 
>
> Key: CASSANDRA-13025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13025
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Sylvain Lebresne
>Priority: Critical
>  Labels: dtest, test-failure
> Fix For: 3.10
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.X_dtest_upgrade/28/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_x_To_indev_3_x/static_columns_with_distinct_test
> {code}
> Error Message
> 
> {code}{code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools/decorators.py", line 46, in 
> wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/upgrade_tests/cql_tests.py", line 
> 4010, in static_columns_with_distinct_test
> rows = list(cursor.execute("SELECT DISTINCT k, s1 FROM test2"))
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 1998, in execute
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile, paging_state).result()
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 3784, in result
> raise self._final_exception
> {code}{code}
> Standard Output
> http://git-wip-us.apache.org/repos/asf/cassandra.git 
> git:7eac22dd41cb09e6d64fb5ac48b2cca3c8840cc8
> Unexpected error in node2 log, error: 
> ERROR [Native-Transport-Requests-2] 2016-12-08 03:20:04,861 Message.java:617 
> - Unexpected exception during request; channel = [id: 0xf4c13f2c, 
> L:/127.0.0.2:9042 - R:/127.0.0.1:52112]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:779)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:741)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:408)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:273)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:232)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:219) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:204) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>

[jira] (CASSANDRA-12563) Stress daemon help is incorrect

2017-01-31 Thread Michael Shuler (JIRA) 

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

Michael Shuler updated CASSANDRA-12563:
---
Fix Version/s: (was: 3.11)
   3.10

> Stress daemon help is incorrect
> ---
>
> Key: CASSANDRA-12563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12563
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Trivial
>  Labels: stress
> Fix For: 3.0.11, 3.10, 4.0
>
>
> It says provide the option -sendToDaemon where as only -send-to and -sendto 
> work
> Fix here:
> https://github.com/chbatey/cassandra-1/tree/stress-daemon



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-12203) AssertionError on compaction after upgrade (2.1.9 -> 3.7)

2017-01-31 Thread Michael Shuler (JIRA) 

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

Michael Shuler updated CASSANDRA-12203:
---
Fix Version/s: (was: 3.11)
   3.10

> AssertionError on compaction after upgrade (2.1.9 -> 3.7)
> -
>
> Key: CASSANDRA-12203
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12203
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 3.7 (upgrade from 2.1.9)
> Java version "1.8.0_91"
> Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-83-generic x86_64)
>Reporter: Roman S. Borschel
>Assignee: Yuki Morishita
>Priority: Critical
> Fix For: 3.0.11, 3.10
>
>
> After upgrading a Cassandra cluster from 2.1.9 to 3.7, one column family 
> (using SizeTieredCompaction) repeatedly and continuously failed compaction 
> (and thus also repair) across the cluster, with all nodes producing the 
> following errors in the logs:
> {noformat}
> 016-07-14T09:29:47.96855 |srv=cassandra|ERROR: Exception in thread 
> Thread[CompactionExecutor:3,1,main]
> 2016-07-14T09:29:47.96858 |srv=cassandra|java.lang.AssertionError: null
> 2016-07-14T09:29:47.96859 |srv=cassandra|   at 
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$TombstoneTracker.openNew(UnfilteredDeserializer.java:650)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96860 |srv=cassandra|   at 
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:423)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96860 |srv=cassandra|   at 
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:298)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96860 |srv=cassandra|   at 
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.readStaticRow(SSTableSimpleIterator.java:133)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96861 |srv=cassandra|   at 
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.(SSTableIdentityIterator.java:57)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96861 |srv=cassandra|   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:334)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96862 |srv=cassandra|   at 
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96862 |srv=cassandra|   at 
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:70)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96863 |srv=cassandra|   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:109)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96863 |srv=cassandra|   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:100)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96864 |srv=cassandra|   at 
> org.apache.cassandra.utils.MergeIterator$Candidate.consume(MergeIterator.java:408)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96864 |srv=cassandra|   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:203)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96865 |srv=cassandra|   at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:156)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96865 |srv=cassandra|   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96866 |srv=cassandra|   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:150)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96866 |srv=cassandra|   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96867 |srv=cassandra|   at 
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96867 |srv=cassandra|   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
>  ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96867 |srv=cassandra|   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-3.7.jar:3.7]
> 2016-07-14T09:29:47.96868

[2/3] cassandra git commit: Improved docs around logged batches by noting the optimization when only a single partition is referenced

2017-01-31 Thread mshuler 
Improved docs around logged batches by noting the optimization when only a 
single partition is referenced

patch by Jon Haddad; reviewed by Michael Shuler for CASSANDRA-13160


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

Branch: refs/heads/trunk
Commit: 5e40fd9fa18bd0939450e657b0b6b0b86ad1f4c9
Parents: 3cf4152
Author: Jon Haddad 
Authored: Thu Jan 26 17:42:02 2017 -0800
Committer: Michael Shuler 
Committed: Tue Jan 31 14:53:32 2017 -0600

--
 doc/source/cql/dml.rst | 1 +
 1 file changed, 1 insertion(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e40fd9f/doc/source/cql/dml.rst
--
diff --git a/doc/source/cql/dml.rst b/doc/source/cql/dml.rst
index 1b0f80b..1308de5 100644
--- a/doc/source/cql/dml.rst
+++ b/doc/source/cql/dml.rst
@@ -501,6 +501,7 @@ Note that:
   resolution procedure in the case of `timestamp ties 
`__, operations may
   be applied in an order that is different from the order they are listed in 
the ``BATCH`` statement. To force a
   particular operation ordering, you must specify per-operation timestamps.
+- A LOGGED batch to a single partition will be converted to an UNLOGGED batch 
as an optimization.
 
 .. _unlogged-batches:

[jira] (CASSANDRA-13160) batch documentation should note the single partition optimization

2017-01-31 Thread Michael Shuler (JIRA) 

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

Michael Shuler updated CASSANDRA-13160:
---
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

Committed to cassandra-3.11 branch and merged up. Thanks!

https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=5e40fd9fa18bd0939450e657b0b6b0b86ad1f4c9

> batch documentation should note the single partition optimization
> -
>
> Key: CASSANDRA-13160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13160
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Minor
> Fix For: 4.0, 3.11
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-01-31 Thread mshuler 
Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: 8c2fcae336da8a4605e676dbb2513fa87f1bc37e
Parents: 1a4696c 5e40fd9
Author: Michael Shuler 
Authored: Tue Jan 31 14:55:15 2017 -0600
Committer: Michael Shuler 
Committed: Tue Jan 31 14:55:15 2017 -0600

--
 doc/source/cql/dml.rst | 1 +
 1 file changed, 1 insertion(+)
--

[1/3] cassandra git commit: Improved docs around logged batches by noting the optimization when only a single partition is referenced

2017-01-31 Thread mshuler 
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.11 3cf415279 -> 5e40fd9fa
  refs/heads/trunk 1a4696c3c -> 8c2fcae33


Improved docs around logged batches by noting the optimization when only a 
single partition is referenced

patch by Jon Haddad; reviewed by Michael Shuler for CASSANDRA-13160


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

Branch: refs/heads/cassandra-3.11
Commit: 5e40fd9fa18bd0939450e657b0b6b0b86ad1f4c9
Parents: 3cf4152
Author: Jon Haddad 
Authored: Thu Jan 26 17:42:02 2017 -0800
Committer: Michael Shuler 
Committed: Tue Jan 31 14:53:32 2017 -0600

--
 doc/source/cql/dml.rst | 1 +
 1 file changed, 1 insertion(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e40fd9f/doc/source/cql/dml.rst
--
diff --git a/doc/source/cql/dml.rst b/doc/source/cql/dml.rst
index 1b0f80b..1308de5 100644
--- a/doc/source/cql/dml.rst
+++ b/doc/source/cql/dml.rst
@@ -501,6 +501,7 @@ Note that:
   resolution procedure in the case of `timestamp ties 
`__, operations may
   be applied in an order that is different from the order they are listed in 
the ``BATCH`` statement. To force a
   particular operation ordering, you must specify per-operation timestamps.
+- A LOGGED batch to a single partition will be converted to an UNLOGGED batch 
as an optimization.
 
 .. _unlogged-batches:

[jira] (CASSANDRA-13160) batch documentation should note the single partition optimization

2017-01-31 Thread Michael Shuler (JIRA) 

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

Michael Shuler commented on CASSANDRA-13160:


dropping 2.2 and 3.0 - doc doesn't exist in those branches

> batch documentation should note the single partition optimization
> -
>
> Key: CASSANDRA-13160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13160
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Minor
> Fix For: 4.0, 3.11
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13160) batch documentation should note the single partition optimization

2017-01-31 Thread Michael Shuler (JIRA) 

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

Michael Shuler updated CASSANDRA-13160:
---
Fix Version/s: (was: 3.0.11)
   (was: 2.2.9)

> batch documentation should note the single partition optimization
> -
>
> Key: CASSANDRA-13160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13160
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Minor
> Fix For: 4.0, 3.11
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13160) batch documentation should note the single partition optimization

2017-01-31 Thread Michael Shuler (JIRA) 

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

Michael Shuler updated CASSANDRA-13160:
---
Fix Version/s: 3.11
   4.0
   3.0.11
   2.2.9

> batch documentation should note the single partition optimization
> -
>
> Key: CASSANDRA-13160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13160
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Minor
> Fix For: 2.2.9, 3.0.11, 4.0, 3.11
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13160) batch documentation should note the single partition optimization

2017-01-31 Thread Michael Shuler (JIRA) 

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

Michael Shuler updated CASSANDRA-13160:
---
Status: Ready to Commit  (was: Patch Available)

> batch documentation should note the single partition optimization
> -
>
> Key: CASSANDRA-13160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13160
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Minor
> Fix For: 2.2.9, 3.0.11, 4.0, 3.11
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13160) batch documentation should note the single partition optimization

2017-01-31 Thread Michael Shuler (JIRA) 

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

Michael Shuler updated CASSANDRA-13160:
---
Reviewer: Michael Shuler

> batch documentation should note the single partition optimization
> -
>
> Key: CASSANDRA-13160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13160
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13160) batch documentation should note the single partition optimization

2017-01-31 Thread Michael Shuler (JIRA) 

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

Michael Shuler commented on CASSANDRA-13160:


Looks good to me. Setting to 2.2 and up.

> batch documentation should note the single partition optimization
> -
>
> Key: CASSANDRA-13160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13160
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13090) Coalescing strategy sleeps too much

2017-01-31 Thread Ariel Weisberg (JIRA) 

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

Ariel Weisberg edited comment on CASSANDRA-13090 at 1/31/17 8:20 PM:
-

I'm not sure why diff stat reports that, but if you actually do the merge you 
don't get the extra stuff.

I can reproduce what you are talking about though.

If you need help getting going with the dtests ping me on IRC. I find them to 
be non-trivial to get working.


was (Author: aweisberg):
I'm not sure why diff stat reports that, but if you actually do the merge you 
don't get the extra stuff.

I can reproduce what you are talking about though.

> Coalescing strategy sleeps too much
> ---
>
> Key: CASSANDRA-13090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13090
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 3.x
>
> Attachments: 0001-Fix-wait-time-coalescing-CASSANDRA-13090-2.patch, 
> 0001-Fix-wait-time-coalescing-CASSANDRA-13090.patch
>
>
> With the current code maybeSleep is called even if we managed to take 
> maxItems out of the backlog. In this case we should really avoid sleeping 
> because it means that backlog is building up.
> I'll send a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13090) Coalescing strategy sleeps too much

2017-01-31 Thread Ariel Weisberg (JIRA) 

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

Ariel Weisberg commented on CASSANDRA-13090:


I'm not sure why diff stat reports that, but if you actually do the merge you 
don't get the extra stuff.

I can reproduce what you are talking about though.

> Coalescing strategy sleeps too much
> ---
>
> Key: CASSANDRA-13090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13090
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 3.x
>
> Attachments: 0001-Fix-wait-time-coalescing-CASSANDRA-13090-2.patch, 
> 0001-Fix-wait-time-coalescing-CASSANDRA-13090.patch
>
>
> With the current code maybeSleep is called even if we managed to take 
> maxItems out of the backlog. In this case we should really avoid sleeping 
> because it means that backlog is building up.
> I'll send a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13090) Coalescing strategy sleeps too much

2017-01-31 Thread Corentin Chary (JIRA) 

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

Corentin Chary commented on CASSANDRA-13090:


What I mean by "significant diff between your trunk and the original trunk."

{code}
$ git fetch origin 
$ git fetch aweisberg 
$ git diff origin/trunk aweisberg/cassandra-13090-trunk --stat
...
585 files changed, 11085 insertions(+), 10474 deletions(-)
{code}

Am I missing anything that could explain this diff ? 
I'll also try to run the dtests on my workstation tomorrow based on your branch.

> Coalescing strategy sleeps too much
> ---
>
> Key: CASSANDRA-13090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13090
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 3.x
>
> Attachments: 0001-Fix-wait-time-coalescing-CASSANDRA-13090-2.patch, 
> 0001-Fix-wait-time-coalescing-CASSANDRA-13090.patch
>
>
> With the current code maybeSleep is called even if we managed to take 
> maxItems out of the backlog. In this case we should really avoid sleeping 
> because it means that backlog is building up.
> I'll send a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13052) Repair process is violating the start/end token limits for small ranges

2017-01-31 Thread Blake Eggleston (JIRA) 

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

Blake Eggleston updated CASSANDRA-13052:

Reviewer: Blake Eggleston

> Repair process is violating the start/end token limits for small ranges
> ---
>
> Key: CASSANDRA-13052
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13052
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: We tried this in 2.0.14 and 3.9, same bug.
>Reporter: Cristian P
>Assignee: Stefan Podkowinski
> Attachments: 13052-2.1.patch, ccm_reproduce-13052.txt, 
> system-dev-debug-13052.log
>
>
> We tried to do a single token repair by providing 2 consecutive token values 
> for a large column family. We soon notice heavy streaming and according to 
> the logs the number of ranges streamed was in thousands.
> After investigation we found a bug in the two partitioner classes we use 
> (RandomPartitioner and Murmur3Partitioner).
> The midpoint method used by MerkleTree.differenceHelper method to find ranges 
> with differences for streaming returns abnormal values (way out of the 
> initial range requested for repair) if the repair requested range is small (I 
> expect smaller than 2^15).
> Here is the simple code to reproduce the bug for Murmur3Partitioner:
> Token left = new Murmur3Partitioner.LongToken(123456789L);
> Token right = new Murmur3Partitioner.LongToken(123456789L);
> IPartitioner partitioner = new Murmur3Partitioner();
> Token midpoint = partitioner.midpoint(left, right);
> System.out.println("Murmur3: [ " + left.getToken() + " : " + 
> midpoint.getToken() + " : " + right.getToken() + " ]");
> The output is:
> Murmur3: [ 123456789 : -9223372036731319019 : 123456789 ]
> Note that the midpoint token is nowhere near the suggested repair range. This 
> will happen if during the parsing of the tree (in 
> MerkleTree.differenceHelper) in search for differences  there isn't enough 
> tokens for the split and the subrange becomes 0 (left.token=right.token) as 
> in the above test.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13079) Repair doesn't work after several replication factor changes

2017-01-31 Thread Joshua McKenzie (JIRA) 

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

Joshua McKenzie reassigned CASSANDRA-13079:
---

Assignee: Paulo Motta

> Repair doesn't work after several replication factor changes
> 
>
> Key: CASSANDRA-13079
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13079
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Debian 
>Reporter: Vladimir Yudovin
>Assignee: Paulo Motta
>Priority: Critical
>
> Scenario:
> Start two nodes cluster.
> Create keyspace with rep.factor *one*:
> CREATE KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> CREATE TABLE rep.data (str text PRIMARY KEY );
> INSERT INTO rep.data (str) VALUES ( 'qwerty');
> Run *nodetool flush* on all nodes. On one of them table files are created.
> Change replication factor to *two*:
> ALTER KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 2};
> Run repair, then *nodetool flush* on all nodes. On all nodes table files are 
> created.
> Change replication factor to *one*:
> ALTER KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> Then *nodetool cleanup*, only on initial node remained data files.
> Change replication factor to *two* again:
> ALTER KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 2};
> Run repair, then *nodetool flush* on all nodes. No data files on second node 
> (though expected, as after first repair/flush).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-12663) Allow per DC segregation, grant user to create different indices per datacenter on tables

2017-01-31 Thread Justin Cameron (JIRA) 

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

Justin Cameron commented on CASSANDRA-12663:


+1. This would be great

> Allow per DC segregation, grant user to create different indices per 
> datacenter on tables
> -
>
> Key: CASSANDRA-12663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12663
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Core
>Reporter: Bhuvan Rawal
>
> For analytics & auditing purposes it becomes essential to serve different 
> access patterns than that modeled from a partition key fetch perspective, 
> although a limited reads are needed by users but if enabled cluster wide it 
> will require index write for every row written on that table on every single 
> node on every DC even the one which may be serving read operations. A user 
> may not want to have indices built on Transactional DC on every write, that 
> computation and disk utilization may not be useful as the Analytics may 
> possibly be performed on other DC.
> It will be a plus to have analytics / auditing workload built inside 
> Cassandra itself using native secondary indices / SASI indices / Stratio by 
> creating indices for a specific datacenter and not having to ship off data to 
> other index stores like Elasticsearch through application.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (CASSANDRA-13090) Coalescing strategy sleeps too much

2017-01-31 Thread Ariel Weisberg (JIRA) 

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

Ariel Weisberg commented on CASSANDRA-13090:


Can you be more specific, maybe link to what you are talking about? I looked at 
trunk and 3.11 and they look like the patch to me. I also check and they are 
based off recent trunk (last commit Jan 27).

I am talking about the dtests where 500 tests fails.

There is this in the logs
{noformat}
ERROR [MessagingService-Outgoing-/127.0.0.1-Gossip] 2017-01-27 22:19:28,638 
OutboundTcpConnection.java:334 - error writing to /127.0.0.1
java.lang.NullPointerException: null
at 
org.apache.cassandra.io.util.UnbufferedDataOutputStreamPlus.writeUTF(UnbufferedDataOutputStreamPlus.java:256)
 ~[main/:na]
at 
org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.writeUTF(BufferedDataOutputStreamPlus.java:304)
 ~[main/:na]
at 
org.apache.cassandra.gms.GossipDigestSynSerializer.serialize(GossipDigestSyn.java:86)
 ~[main/:na]
at 
org.apache.cassandra.gms.GossipDigestSynSerializer.serialize(GossipDigestSyn.java:81)
 ~[main/:na]
at org.apache.cassandra.net.MessageOut.serialize(MessageOut.java:120) 
~[main/:na]
at 
org.apache.cassandra.net.OutboundTcpConnection.writeInternal(OutboundTcpConnection.java:351)
 [main/:na]
at 
org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:303)
 [main/:na]
at 
org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:237)
 [main/:na]
{noformat}

> Coalescing strategy sleeps too much
> ---
>
> Key: CASSANDRA-13090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13090
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 3.x
>
> Attachments: 0001-Fix-wait-time-coalescing-CASSANDRA-13090-2.patch, 
> 0001-Fix-wait-time-coalescing-CASSANDRA-13090.patch
>
>
> With the current code maybeSleep is called even if we managed to take 
> maxItems out of the backlog. In this case we should really avoid sleeping 
> because it means that backlog is building up.
> I'll send a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[cassandra] Git Push Summary

2017-01-31 Thread mshuler 
Repository: cassandra
Updated Tags:  refs/tags/3.10-tentative [created] 3cf415279