[jira] [Updated] (CASSANDRA-10752) CQL.textile wasn't updated for CASSANDRA-6839

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-10752:

Fix Version/s: 3.x
   3.0.x
   2.2.x
   2.1.x

> CQL.textile wasn't updated for CASSANDRA-6839
> -
>
> Key: CASSANDRA-10752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10752
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation and Website
>Reporter: Jeremiah Jordan
>Assignee: Tyler Hobbs
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> CQL.textile wasn't updated after CASSANDRA-6839 added inequalities for LWT's.



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

[jira] [Commented] (CASSANDRA-11258) Repair scheduling - Resource locking API

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11258:
-

bq. However, if we want to visualize all data center locks to the user, it 
would be more complex to do so.

That's a good point, we might want to view remote locks in the future so I'm 
not sure {{LDCRS}} would be a good fit in this case. We could maybe save the 
remote lock info in the local keyspace but this wouldn't be very different (and 
probably more complex) than having a global keyspace. And we might also want to 
introduce global locks in the future, so we would need a global keyspace in 
addition to the local one.

bq. Should we start with SimpleStrategy and a replication of 3 then?

Yes, I think we should advance the implementation based on {{SimpleStrategy}} 
for now and focus on single DC first, and think better about multi-DC support 
in a separate task (since it may become easier to reason about multi-DC details 
when we have a full scheduled repair cycle working for a single DC).

> Repair scheduling - Resource locking API
> 
>
> Key: CASSANDRA-11258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11258
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Minor
>
> Create a resource locking API & implementation that is able to lock a 
> resource in a specified data center. It should handle priorities to avoid 
> node starvation.



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

[jira] [Commented] (CASSANDRA-6377) ALLOW FILTERING should allow seq scan filtering

[Srini (JIRA)]

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

Srini commented on CASSANDRA-6377:
--

Is this ready to test? Which version we should use?  Our use case is that  
during the read we have the primary key and only few columns of the cluster key 
(not in the sequence). We would like to filter the rows in the partition that 
satisfy the primary key and partial columns of the cluster key.

> ALLOW FILTERING should allow seq scan filtering
> ---
>
> Key: CASSANDRA-6377
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6377
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Benjamin Lerer
>  Labels: cql
> Fix For: 2.2.6, 3.5, 3.0.5
>
>
> CREATE TABLE emp_table2 (
> empID int PRIMARY KEY,
> firstname text,
> lastname text,
> b_mon text,
> b_day text,
> b_yr text,
> );
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (100,'jane','doe','oct','31','1980');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (101,'john','smith','jan','01','1981');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (102,'mary','jones','apr','15','1982');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (103,'tim','best','oct','25','1982');
>
> SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2 
> WHERE b_mon='oct' ALLOW FILTERING;
> Bad Request: No indexed columns present in by-columns clause with Equal 
> operator



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

[jira] [Comment Edited] (CASSANDRA-10990) Support streaming of older version sstables in 3.0

[Paulo Motta (JIRA)]

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

Paulo Motta edited comment on CASSANDRA-10990 at 3/5/16 2:52 AM:
-

Updated branch with reworked {{RewindableDataInputStreamPlus}}, now treating 
the spill file as circular buffer with max size. Now required space for spill 
buffer file of legacy {{StreamDeserializer}} is {{max(sstableSize, MAX_INT)}}, 
capping the max required space (and max partition size) for streaming 
legacy/compact sstables on ~2GB. I also updated documentation and tests. WDYT 
[~yukim]?

Besides that, I added a new 
[dtest|https://github.com/pauloricardomg/cassandra-dtest/commit/b59ea329a5b9302372c57956f7015111fd47a4ae]
 for testing repair of older version sstables on 3.0+, and it seems to work. 
Now we have the following dtests:
* [bootstrap 
dtests|https://github.com/pauloricardomg/cassandra-dtest/blob/10990/upgrade_8099_test.py#L340]
* [sstable loader 
dtests|https://github.com/pauloricardomg/cassandra-dtest/blob/10990/sstable_generation_loading_test.py#L181]
* [repair 
dtests|https://github.com/pauloricardomg/cassandra-dtest/commit/b59ea329a5b9302372c57956f7015111fd47a4ae]

For simplicity, I opted for writing the old streamed sstables in the new format 
without {{EncodingStats}} (since there is no {{SerializationHeader}} 
available), what may make these sstables less optimized in terms of storage 
space from what I understood. Do you think we should construct these stats when 
receiving the sstable or not bother [~slebresne] ? Also, do you recall of any 
other edge case we should watch here?

Thanks!


was (Author: pauloricardomg):
Updated branch with reworked {{RewindableDataInputStreamPlus}}, now treating 
the spill file as circular buffer with max size. Now required space for spill 
buffer file of legacy {{StreamDeserializer}} is {{max(sstableSize, MAX_INT)}}, 
capping the max required space for streaming older version sstables on ~2GB. I 
also updated documentation and tests. WDYT [~yukim]?

Besides that, I added a new 
[dtest|https://github.com/pauloricardomg/cassandra-dtest/commit/b59ea329a5b9302372c57956f7015111fd47a4ae]
 for testing repair of older version sstables on 3.0+, and it seems to work. 
Now we have the following dtests:
* [bootstrap 
dtests|https://github.com/pauloricardomg/cassandra-dtest/blob/10990/upgrade_8099_test.py#L340]
* [sstable loader 
dtests|https://github.com/pauloricardomg/cassandra-dtest/blob/10990/sstable_generation_loading_test.py#L181]
* [repair 
dtests|https://github.com/pauloricardomg/cassandra-dtest/commit/b59ea329a5b9302372c57956f7015111fd47a4ae]

For simplicity, I opted for writing the old streamed sstables in the new format 
without {{EncodingStats}} (since there is no {{SerializationHeader}} 
available), what may make these sstables less optimized in terms of storage 
space from what I understood. Do you think we should construct these stats when 
receiving the sstable or not bother [~slebresne] ? Also, do you recall of any 
other edge case we should watch here?

Thanks!

> Support streaming of older version sstables in 3.0
> --
>
> Key: CASSANDRA-10990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10990
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeremy Hanna
>Assignee: Paulo Motta
>
> In 2.0 we introduced support for streaming older versioned sstables 
> (CASSANDRA-5772).  In 3.0, because of the rewrite of the storage layer, this 
> became no longer supported.  So currently, while 3.0 can read sstables in the 
> 2.1/2.2 format, it cannot stream the older versioned sstables.  We should do 
> some work to make this still possible to be consistent with what 
> CASSANDRA-5772 provided.



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

[jira] [Commented] (CASSANDRA-10990) Support streaming of older version sstables in 3.0

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10990:
-

Updated branch with reworked {{RewindableDataInputStreamPlus}}, now treating 
the spill file as circular buffer with max size. Now required space for spill 
buffer file of legacy {{StreamDeserializer}} is {{max(sstableSize, MAX_INT)}}, 
capping the max required space for streaming older version sstables on ~2GB. I 
also updated documentation and tests. WDYT [~yukim]?

Besides that, I added a new 
[dtest|https://github.com/pauloricardomg/cassandra-dtest/commit/b59ea329a5b9302372c57956f7015111fd47a4ae]
 for testing repair of older version sstables on 3.0+, and it seems to work. 
Now we have the following dtests:
* [bootstrap 
dtests|https://github.com/pauloricardomg/cassandra-dtest/blob/10990/upgrade_8099_test.py#L340]
* [sstable loader 
dtests|https://github.com/pauloricardomg/cassandra-dtest/blob/10990/sstable_generation_loading_test.py#L181]
* [repair 
dtests|https://github.com/pauloricardomg/cassandra-dtest/commit/b59ea329a5b9302372c57956f7015111fd47a4ae]

For simplicity, I opted for writing the old streamed sstables in the new format 
without {{EncodingStats}} (since there is no {{SerializationHeader}} 
available), what may make these sstables less optimized in terms of storage 
space from what I understood. Do you think we should construct these stats when 
receiving the sstable or not bother [~slebresne] ? Also, do you recall of any 
other edge case we should watch here?

Thanks!

> Support streaming of older version sstables in 3.0
> --
>
> Key: CASSANDRA-10990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10990
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeremy Hanna
>Assignee: Paulo Motta
>
> In 2.0 we introduced support for streaming older versioned sstables 
> (CASSANDRA-5772).  In 3.0, because of the rewrite of the storage layer, this 
> became no longer supported.  So currently, while 3.0 can read sstables in the 
> 2.1/2.2 format, it cannot stream the older versioned sstables.  We should do 
> some work to make this still possible to be consistent with what 
> CASSANDRA-5772 provided.



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

[jira] [Comment Edited] (CASSANDRA-10726) Read repair inserts should not be blocking

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis edited comment on CASSANDRA-10726 at 3/5/16 12:40 AM:
-

Yes.  And if two of the nodes agree on the most recent value then we don't need 
to block on the third being updated since our monotonicity of future quorum 
reads is already assured.


was (Author: jbellis):
Yes.  And if two of the nodes agree on the most recent value then we don't need 
to block on the third being updated.

> Read repair inserts should not be blocking
> --
>
> Key: CASSANDRA-10726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10726
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination
>Reporter: Richard Low
>
> Today, if there’s a digest mismatch in a foreground read repair, the insert 
> to update out of date replicas is blocking. This means, if it fails, the read 
> fails with a timeout. If a node is dropping writes (maybe it is overloaded or 
> the mutation stage is backed up for some other reason), all reads to a 
> replica set could fail. Further, replicas dropping writes get more out of 
> sync so will require more read repair.
> The comment on the code for why the writes are blocking is:
> {code}
> // wait for the repair writes to be acknowledged, to minimize impact on any 
> replica that's
> // behind on writes in case the out-of-sync row is read multiple times in 
> quick succession
> {code}
> but the bad side effect is that reads timeout. Either the writes should not 
> be blocking or we should return success for the read even if the write times 
> out.



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

[jira] [Commented] (CASSANDRA-10726) Read repair inserts should not be blocking

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis commented on CASSANDRA-10726:


Yes.  And if two of the nodes agree on the most recent value then we don't need 
to block on the third being updated.

> Read repair inserts should not be blocking
> --
>
> Key: CASSANDRA-10726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10726
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination
>Reporter: Richard Low
>
> Today, if there’s a digest mismatch in a foreground read repair, the insert 
> to update out of date replicas is blocking. This means, if it fails, the read 
> fails with a timeout. If a node is dropping writes (maybe it is overloaded or 
> the mutation stage is backed up for some other reason), all reads to a 
> replica set could fail. Further, replicas dropping writes get more out of 
> sync so will require more read repair.
> The comment on the code for why the writes are blocking is:
> {code}
> // wait for the repair writes to be acknowledged, to minimize impact on any 
> replica that's
> // behind on writes in case the out-of-sync row is read multiple times in 
> quick succession
> {code}
> but the bad side effect is that reads timeout. Either the writes should not 
> be blocking or we should return success for the read even if the write times 
> out.



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

[jira] [Commented] (CASSANDRA-10726) Read repair inserts should not be blocking

[Richard Low (JIRA)]

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

Richard Low commented on CASSANDRA-10726:
-

What do you think [~jbellis] [~slebresne]?

> Read repair inserts should not be blocking
> --
>
> Key: CASSANDRA-10726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10726
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination
>Reporter: Richard Low
>
> Today, if there’s a digest mismatch in a foreground read repair, the insert 
> to update out of date replicas is blocking. This means, if it fails, the read 
> fails with a timeout. If a node is dropping writes (maybe it is overloaded or 
> the mutation stage is backed up for some other reason), all reads to a 
> replica set could fail. Further, replicas dropping writes get more out of 
> sync so will require more read repair.
> The comment on the code for why the writes are blocking is:
> {code}
> // wait for the repair writes to be acknowledged, to minimize impact on any 
> replica that's
> // behind on writes in case the out-of-sync row is read multiple times in 
> quick succession
> {code}
> but the bad side effect is that reads timeout. Either the writes should not 
> be blocking or we should return success for the read even if the write times 
> out.



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

[jira] [Comment Edited] (CASSANDRA-10689) java.lang.OutOfMemoryError: Direct buffer memory

[Digant Modha (JIRA)]

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

Digant Modha edited comment on CASSANDRA-10689 at 3/4/16 10:59 PM:
---

I also have a similar issue:

Top shows process is using 19g memory.  The memory usage grows until node dies. 
 It is started  with -Xmx8g -Xms8g -Xmn2g.

java.lang.OutOfMemoryError: Direct buffer memory
at java.nio.Bits.reserveMemory(Bits.java:658) ~[na:1.8.0_60]
at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) 
~[na:1.8.0_60]
at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) 
~[na:1.8.0_60]
at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:580) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:456) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at io.netty.handler.ssl.SslHandler.flush(SslHandler.java:432) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
org.apache.cassandra.transport.Message$Dispatcher$Flusher.run(Message.java:389) 
~[apache-cassandra-2.1.12.jar:2.1.12]
at 
io.netty.util.concurrent.PromiseTask$RunnableAdapter.call(PromiseTask.java:38) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:123) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:380)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:268) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]



was (Author: dmodha):
I also have a similar issue:
ava.lang.OutOfMemoryError: Direct buffer memory
at java.nio.Bits.reserveMemory(Bits.java:658) ~[na:1.8.0_60]
at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) 
~[na:1.8.0_60]
at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) 
~[na:1.8.0_60]
at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:580) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:456) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at io.netty.handler.ssl.SslHandler.flush(SslHandler.java:432) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 

[jira] [Commented] (CASSANDRA-10689) java.lang.OutOfMemoryError: Direct buffer memory

[Digant Modha (JIRA)]

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

Digant Modha commented on CASSANDRA-10689:
--

I also have a similar issue:
ava.lang.OutOfMemoryError: Direct buffer memory
at java.nio.Bits.reserveMemory(Bits.java:658) ~[na:1.8.0_60]
at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) 
~[na:1.8.0_60]
at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) 
~[na:1.8.0_60]
at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:580) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:456) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at io.netty.handler.ssl.SslHandler.flush(SslHandler.java:432) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:688)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:669)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
org.apache.cassandra.transport.Message$Dispatcher$Flusher.run(Message.java:389) 
~[apache-cassandra-2.1.12.jar:2.1.12]
at 
io.netty.util.concurrent.PromiseTask$RunnableAdapter.call(PromiseTask.java:38) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:123) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:380)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:268) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]


> java.lang.OutOfMemoryError: Direct buffer memory
> 
>
> Key: CASSANDRA-10689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10689
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mlowicki
>
> {code}
> ERROR [SharedPool-Worker-63] 2015-11-11 17:53:16,161 
> JVMStabilityInspector.java:117 - JVM state determined to be unstable.  
> Exiting forcefully due to:
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:658) ~[na:1.7.0_80]
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) 
> ~[na:1.7.0_80]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306) 
> ~[na:1.7.0_80]
> at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:174) 
> ~[na:1.7.0_80]
> at sun.nio.ch.IOUtil.read(IOUtil.java:195) ~[na:1.7.0_80]
> at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:149) 
> ~[na:1.7.0_80]
> at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.decompressChunk(CompressedRandomAccessReader.java:104)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.reBuffer(CompressedRandomAccessReader.java:81)
>  ~[apache-cassandra-2.1.11.jar:2.1.11]  
> at 
> 

[jira] [Commented] (CASSANDRA-10805) Additional Compaction Logging

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-10805:


I've pushed a new version of this branch which is updated for the 
CASSANDRA-6696 changes, and outputs JSON objects. I haven't looked at how to 
use just the parts of logback that we would want to yet, but if the current 
approach looks OK except for reimplementing the log rolling, I'll take a look 
at it early next week.

> Additional Compaction Logging
> -
>
> Key: CASSANDRA-10805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10805
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Compaction, Observability
>Reporter: Carl Yeksigian
>Assignee: Carl Yeksigian
>Priority: Minor
>
> Currently, viewing the results of past compactions requires parsing the log 
> and looking at the compaction history system table, which doesn't have 
> information about, for example, flushed sstables not previously compacted.
> This is a proposal to extend the information captured for compaction. 
> Initially, this would be done through a JMX call, but if it proves to be 
> useful and not much overhead, it might be a feature that could be enabled for 
> the compaction strategy all the time.
> Initial log information would include:
> - The compaction strategy type controlling each column family
> - The set of sstables included in each compaction strategy
> - Information about flushes and compactions, including times and all involved 
> sstables
> - Information about sstables, including generation, size, and tokens
> - Any additional metadata the strategy wishes to add to a compaction or an 
> sstable, like the level of an sstable or the type of compaction being 
> performed



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

[jira] [Created] (CASSANDRA-11307) Inappropriate WARN log message for commit log sync delay when using commitlog_sync: batch

[Gary Ogasawara (JIRA)]

Gary Ogasawara created CASSANDRA-11307:
--

 Summary: Inappropriate WARN log message for commit log sync delay 
when using commitlog_sync: batch
 Key: CASSANDRA-11307
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11307
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Linux
Reporter: Gary Ogasawara
Priority: Minor


In v2.1.11 when using configuration
commitlog_sync: batch
commitlog_sync_batch_window_in_ms: 2

will frequently get this WARN log though there is not a real problem.

WARN  [COMMIT-LOG-WRITER] 2016-03-03 00:40:11,646 
AbstractCommitLogService.java:105 - Out of 142412 commit log syncs over the 
past 300s with average duration of 0.00ms, 35 have exceeded the configured 
commit interval by an average of 3.66ms

WARN  [COMMIT-LOG-WRITER] 2016-03-03 00:45:11,755 
AbstractCommitLogService.java:105 - Out of 104605 commit log syncs over the 
past 300s with average duration of 1.74ms, 18314 have exceeded the configured 
commit interval by an average of 6.33ms

Looks like BatchCommitLogService sets AbstractCommitLogService() 
pollIntervalMillis to the configured commitlog_sync_batch_window_in_ms.  Since 
CASSANDRA-9504, this is by default set to 2 which causes this WARN message to 
be triggered unnecessarily.




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

[jira] [Commented] (CASSANDRA-11278) dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test and tracing_unknown_impl_test

[Russ Hatch (JIRA)]

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

Russ Hatch commented on CASSANDRA-11278:


>From talking with [~tjake] it sounds like we needed to skip these tests using 
>since(3.4), which I've done in the pr above.

Somewhat related, looks like the dtest method post_cassandra_10392 might need a 
little update too, but since should suffice for now.

> dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test 
> and tracing_unknown_impl_test
> 
>
> Key: CASSANDRA-11278
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11278
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Jim Witschey
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/174/testReport/cql_tracing_test/TestCqlTracing/tracing_default_impl_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #174



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

[jira] [Commented] (CASSANDRA-11278) dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test and tracing_unknown_impl_test

[Russ Hatch (JIRA)]

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

Russ Hatch commented on CASSANDRA-11278:


https://github.com/riptano/cassandra-dtest/pull/837

> dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test 
> and tracing_unknown_impl_test
> 
>
> Key: CASSANDRA-11278
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11278
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Jim Witschey
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/174/testReport/cql_tracing_test/TestCqlTracing/tracing_default_impl_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #174



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

[jira] [Updated] (CASSANDRA-11278) dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test and tracing_unknown_impl_test

[Russ Hatch (JIRA)]

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

Russ Hatch updated CASSANDRA-11278:
---
Assignee: Jim Witschey  (was: DS Test Eng)

> dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test 
> and tracing_unknown_impl_test
> 
>
> Key: CASSANDRA-11278
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11278
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Jim Witschey
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/174/testReport/cql_tracing_test/TestCqlTracing/tracing_default_impl_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #174



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

[jira] [Updated] (CASSANDRA-6377) ALLOW FILTERING should allow seq scan filtering

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-6377:
--
   Resolution: Fixed
Fix Version/s: (was: 3.0.x)
   (was: 3.x)
   3.0.5
   3.5
   2.2.6
   Status: Resolved  (was: Patch Available)

Committed into 2.2 at 90fd8deed0d1eaa12906bc80aaf54daf837f3a81
Committed into 3.0 at 9c3855b5fd83b9fa9ffb2e5495e43cbea9855dee and merged into 
3.5 and trunk

> ALLOW FILTERING should allow seq scan filtering
> ---
>
> Key: CASSANDRA-6377
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6377
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Benjamin Lerer
>  Labels: cql
> Fix For: 2.2.6, 3.5, 3.0.5
>
>
> CREATE TABLE emp_table2 (
> empID int PRIMARY KEY,
> firstname text,
> lastname text,
> b_mon text,
> b_day text,
> b_yr text,
> );
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (100,'jane','doe','oct','31','1980');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (101,'john','smith','jan','01','1981');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (102,'mary','jones','apr','15','1982');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (103,'tim','best','oct','25','1982');
>
> SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2 
> WHERE b_mon='oct' ALLOW FILTERING;
> Bad Request: No indexed columns present in by-columns clause with Equal 
> operator



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

[1/7] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 980e476bd -> 6e69c7590


http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java 
b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
index 506bdaf..d8cd3c3 100644
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
@@ -24,6 +24,8 @@ import org.junit.Test;
 
 import junit.framework.Assert;
 import org.apache.cassandra.cql3.UntypedResultSet;
+import org.apache.cassandra.cql3.restrictions.StatementRestrictions;
+import org.apache.cassandra.utils.ByteBufferUtil;
 import org.apache.cassandra.cql3.CQLTester;
 
 import static org.junit.Assert.assertEquals;
@@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue;
  */
 public class SelectTest extends CQLTester
 {
+private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65);
+
 @Test
 public void testSingleClustering() throws Throwable
 {
@@ -387,13 +391,13 @@ public class SelectTest extends CQLTester
row("test", 5, set("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND 
categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories 
CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", 
"notPresent"));
 }
@@ -420,13 +424,13 @@ public class SelectTest extends CQLTester
row("test", 5, list("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ? AND categories CONTAINS ?",
  "test", 5, "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND 
categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING",
@@ -472,19 +476,19 @@ public class SelectTest extends CQLTester
row("test", 5, map("lmn", "foo"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS KEY ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS KEY ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+

[5/7] cassandra git commit: Fix filtering on non-primary key columns for queries without index

[blerer]

Fix filtering on non-primary key columns for queries without index

patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377


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

Branch: refs/heads/trunk
Commit: 9c3855b5fd83b9fa9ffb2e5495e43cbea9855dee
Parents: e01c6dd
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:09:54 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:09:54 2016 +0100

--
 CHANGES.txt |1 +
 .../cassandra/cql3/SingleColumnRelation.java|4 -
 .../restrictions/StatementRestrictions.java |8 +-
 .../cql3/statements/SelectStatement.java|   11 +-
 .../apache/cassandra/db/filter/RowFilter.java   |   51 +-
 .../index/internal/CassandraIndex.java  |   15 +
 .../entities/FrozenCollectionsTest.java |3 +-
 .../validation/entities/SecondaryIndexTest.java |3 +-
 .../cql3/validation/operations/DeleteTest.java  |   10 +-
 .../SelectMultiColumnRelationTest.java  |   54 +-
 .../SelectSingleColumnRelationTest.java |   51 +-
 .../cql3/validation/operations/SelectTest.java  | 1071 +-
 .../cql3/validation/operations/UpdateTest.java  |8 +-
 .../apache/cassandra/index/CustomIndexTest.java |4 +-
 .../index/internal/CassandraIndexTest.java  |   34 +-
 15 files changed, 1205 insertions(+), 123 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 520e66e..7204098 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.5
+ * Fix filtering on non-primary key columns for queries without index 
(CASSANDRA-6377)
  * Fix sstableloader fail when using materialized view (CASSANDRA-11275)
 Merged from 2.2:
  * Only log yaml config once, at startup (CASSANDRA-11217)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
--
diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java 
b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
index e2c0b79..05ba42d 100644
--- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
+++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
@@ -227,10 +227,6 @@ public final class SingleColumnRelation extends Relation
 {
 ColumnSpecification receiver = columnDef;
 
-checkFalse(!columnDef.isPrimaryKeyColumn() && isDense,
-   "Predicates on the non-primary-key column (%s) of a COMPACT 
table are not yet supported",
-   columnDef.name);
-
 if (isIN())
 {
 // We only allow IN on the row key and the clustering key so far, 
never on non-PK columns, and this even if

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java 
b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
index 1c7db4e..797b8e4 100644
--- a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
+++ b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
@@ -50,8 +50,10 @@ import static 
org.apache.cassandra.cql3.statements.RequestValidations.invalidReq
  */
 public final class StatementRestrictions
 {
-public static final String NO_INDEX_FOUND_MESSAGE =
-"No supported secondary index found for the non primary key columns 
restrictions";
+public static final String REQUIRES_ALLOW_FILTERING_MESSAGE =
+"Cannot execute this query as it might involve data filtering and 
" +
+"thus may have unpredictable performance. If you want to execute " 
+
+"this query despite the performance unpredictability, use ALLOW 
FILTERING";
 
 /**
  * The type of statement
@@ -224,7 +226,7 @@ public final class StatementRestrictions
 if (hasQueriableIndex)
 usesSecondaryIndexing = true;
 else if (!useFiltering)
-throw invalidRequest(NO_INDEX_FOUND_MESSAGE);
+throw 
invalidRequest(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE);
 
 indexRestrictions.add(nonPrimaryKeyRestrictions);
 }

[4/7] cassandra git commit: Fix filtering on non-primary key columns for queries without index

[blerer]

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java 
b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
index 8622c98..a7eeeb8 100644
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
@@ -24,6 +24,8 @@ import org.junit.Test;
 
 import junit.framework.Assert;
 import org.apache.cassandra.cql3.UntypedResultSet;
+import org.apache.cassandra.cql3.restrictions.StatementRestrictions;
+import org.apache.cassandra.utils.ByteBufferUtil;
 import org.apache.cassandra.cql3.CQLTester;
 
 import static org.junit.Assert.assertEquals;
@@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue;
  */
 public class SelectTest extends CQLTester
 {
+private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65);
+
 @Test
 public void testSingleClustering() throws Throwable
 {
@@ -366,7 +370,7 @@ public class SelectTest extends CQLTester
 }
 
 @Test
-public void testSetContains() throws Throwable
+public void testSetContainsWithIndex() throws Throwable
 {
 createTable("CREATE TABLE %s (account text, id int, categories 
set, PRIMARY KEY (account, id))");
 createIndex("CREATE INDEX ON %s(categories)");
@@ -387,19 +391,19 @@ public class SelectTest extends CQLTester
row("test", 5, set("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND 
categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories 
CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", 
"notPresent"));
 }
 
 @Test
-public void testListContains() throws Throwable
+public void testListContainsWithIndex() throws Throwable
 {
 createTable("CREATE TABLE %s (account text, id int, categories 
list, PRIMARY KEY (account, id))");
 createIndex("CREATE INDEX ON %s(categories)");
@@ -420,13 +424,13 @@ public class SelectTest extends CQLTester
row("test", 5, list("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ? AND categories CONTAINS ?",
  "test", 5, "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND 
categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING",
@@ -434,7 +438,7 @@ public class SelectTest extends CQLTester
 }
 
 @Test
-public void testListContainsWithFiltering() throws Throwable
+public void testListContainsWithIndexAndFiltering() throws Throwable
 {
 createTable("CREATE TABLE %s (e int PRIMARY KEY, f list, s 
int)");
 createIndex("CREATE INDEX ON %s(f)");
@@ -452,7 +456,7 @@ public class SelectTest extends CQLTester
 

[2/7] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families

[blerer]

Fix filtering on non-primary key columns for thrift static column families

patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377


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

Branch: refs/heads/trunk
Commit: 90fd8deed0d1eaa12906bc80aaf54daf837f3a81
Parents: 0934542
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:05:13 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:05:13 2016 +0100

--
 CHANGES.txt |   2 +
 .../cassandra/cql3/SingleColumnRelation.java|   4 -
 .../cql3/restrictions/AbstractRestriction.java  |   4 +-
 .../restrictions/StatementRestrictions.java |  25 +-
 .../cql3/statements/SelectStatement.java|   8 +-
 .../db/index/SecondaryIndexManager.java |  43 +-
 .../entities/FrozenCollectionsTest.java |   4 +-
 .../validation/entities/SecondaryIndexTest.java |   2 +-
 .../cql3/validation/entities/UFAuthTest.java|  11 -
 .../entities/UFIdentificationTest.java  |   6 +-
 .../SelectMultiColumnRelationTest.java  |  31 +-
 .../SelectSingleColumnRelationTest.java |  34 +-
 .../cql3/validation/operations/SelectTest.java  | 829 ++-
 .../db/index/PerRowSecondaryIndexTest.java  |   4 +-
 14 files changed, 915 insertions(+), 92 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index db6d79d..5631a28 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
 2.2.6
+ * Fix filtering on non-primary key columns for thrift static column families
+   (CASSANDRA-6377)
  * Only log yaml config once, at startup (CASSANDRA-11217)
  * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
  * Reference leak with parallel repairs on the same table (CASSANDRA-11215)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
--
diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java 
b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
index b206631..dbae5f0 100644
--- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
+++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
@@ -196,10 +196,6 @@ public final class SingleColumnRelation extends Relation
 {
 ColumnSpecification receiver = columnDef;
 
-checkFalse(columnDef.isCompactValue(),
-   "Predicates on the non-primary-key column (%s) of a COMPACT 
table are not yet supported",
-   columnDef.name);
-
 if (isIN())
 {
 // We only allow IN on the row key and the clustering key so far, 
never on non-PK columns, and this even if

http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java 
b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
index dac7203..385bfbc 100644
--- a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
+++ b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
@@ -93,8 +93,8 @@ abstract class AbstractRestriction  implements Restriction
  ByteBuffer value)
  throws 
InvalidRequestException
 {
-checkNotNull(value, "Unsupported null value for indexed column %s", 
columnSpec.name);
-checkBindValueSet(value, "Unsupported unset value for indexed column 
%s", columnSpec.name);
+checkNotNull(value, "Unsupported null value for column %s", 
columnSpec.name);
+checkBindValueSet(value, "Unsupported unset value for column %s", 
columnSpec.name);
 checkFalse(value.remaining() > 0x, "Index expression values may 
not be larger than 64K");
 return value;
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java 
b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
index 55c6808..e0cf743 

[3/7] cassandra git commit: Merge branch cassandra-2.2 into cassandra-3.0

[blerer]

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/e01c6dd3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e01c6dd3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e01c6dd3

Branch: refs/heads/trunk
Commit: e01c6dd3aae90c9eeb4fce7d8dd18123f02fed48
Parents: 19bccb4 90fd8de
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:07:23 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:07:35 2016 +0100

--

--

[7/7] cassandra git commit: Merge branch cassandra-3.5 into trunk

[blerer]

Merge branch cassandra-3.5 into trunk


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

Branch: refs/heads/trunk
Commit: 6e69c75900f3640195130085ad69daa1659184eb
Parents: 980e476 8c83c8e
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:15:17 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:15:29 2016 +0100

--
 CHANGES.txt |1 +
 .../cassandra/cql3/SingleColumnRelation.java|4 -
 .../restrictions/StatementRestrictions.java |   25 +-
 .../cql3/statements/SelectStatement.java|   12 +-
 .../apache/cassandra/db/filter/RowFilter.java   |   50 +-
 .../index/internal/CassandraIndex.java  |   23 +-
 .../entities/FrozenCollectionsTest.java |3 +-
 .../validation/entities/SecondaryIndexTest.java |3 +-
 .../cql3/validation/operations/DeleteTest.java  |   10 +-
 .../SelectMultiColumnRelationTest.java  |   54 +-
 .../SelectSingleColumnRelationTest.java |   51 +-
 .../cql3/validation/operations/SelectTest.java  | 1063 +-
 .../cql3/validation/operations/UpdateTest.java  |8 +-
 .../apache/cassandra/index/CustomIndexTest.java |4 +-
 .../index/internal/CassandraIndexTest.java  |   34 +-
 15 files changed, 1199 insertions(+), 146 deletions(-)
--

[6/7] cassandra git commit: Merge branch cassandra-3.0 into cassandra-3.5

[blerer]

Merge branch cassandra-3.0 into cassandra-3.5


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

Branch: refs/heads/trunk
Commit: 8c83c8edab4f1c23c382bb0ac076cab44d5f4dda
Parents: a8dc14d 9c3855b
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:12:33 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:13:35 2016 +0100

--
 CHANGES.txt |1 +
 .../cassandra/cql3/SingleColumnRelation.java|4 -
 .../restrictions/StatementRestrictions.java |   25 +-
 .../cql3/statements/SelectStatement.java|   12 +-
 .../apache/cassandra/db/filter/RowFilter.java   |   50 +-
 .../index/internal/CassandraIndex.java  |   23 +-
 .../entities/FrozenCollectionsTest.java |3 +-
 .../validation/entities/SecondaryIndexTest.java |3 +-
 .../cql3/validation/operations/DeleteTest.java  |   10 +-
 .../SelectMultiColumnRelationTest.java  |   54 +-
 .../SelectSingleColumnRelationTest.java |   51 +-
 .../cql3/validation/operations/SelectTest.java  | 1063 +-
 .../cql3/validation/operations/UpdateTest.java  |8 +-
 .../apache/cassandra/index/CustomIndexTest.java |4 +-
 .../index/internal/CassandraIndexTest.java  |   34 +-
 15 files changed, 1199 insertions(+), 146 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/CHANGES.txt
--
diff --cc CHANGES.txt
index a6cae21,7204098..4c21d66
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,5 -1,5 +1,6 @@@
 -3.0.5
 +3.5
 +Merged from 3.0:
+  * Fix filtering on non-primary key columns for queries without index 
(CASSANDRA-6377)
   * Fix sstableloader fail when using materialized view (CASSANDRA-11275)
  Merged from 2.2:
   * Only log yaml config once, at startup (CASSANDRA-11217)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --cc src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index d3a79d0,51d675b..2f4d468
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@@ -702,9 -696,8 +696,7 @@@ public class SelectStatement implement
  // we want to include static columns and we're done.
  if (!partition.hasNext())
  {
- if (!staticRow.isEmpty()
- && (!restrictions.hasClusteringColumnsRestriction() || 
cfm.isStaticCompactTable())
- && !restrictions.hasRegularColumnsRestriction())
 -if (!staticRow.isEmpty() && 
(!restrictions.usesSecondaryIndexing() || cfm.isStaticCompactTable())
 -&& !restrictions.hasClusteringColumnsRestriction())
++if (!staticRow.isEmpty() && 
(!restrictions.hasClusteringColumnsRestriction() || cfm.isStaticCompactTable()))
  {
  result.newRow(protocolVersion);
  for (ColumnDefinition def : selection.getColumns())

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/db/filter/RowFilter.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
--
diff --cc src/java/org/apache/cassandra/index/internal/CassandraIndex.java
index f503e59,74d3f5d..c3e75e0
--- a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
+++ b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
@@@ -5,12 -5,13 +5,11 @@@ import java.util.*
  import java.util.concurrent.Callable;
  import java.util.concurrent.Future;
  import java.util.function.BiFunction;
 -import java.util.regex.Matcher;
--import java.util.regex.Pattern;
  import java.util.stream.Collectors;
  import java.util.stream.StreamSupport;
  
  import com.google.common.collect.ImmutableSet;
- import org.apache.cassandra.index.TargetParser;
 -import 

[2/6] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families

[blerer]

Fix filtering on non-primary key columns for thrift static column families

patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377


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

Branch: refs/heads/cassandra-3.5
Commit: 90fd8deed0d1eaa12906bc80aaf54daf837f3a81
Parents: 0934542
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:05:13 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:05:13 2016 +0100

--
 CHANGES.txt |   2 +
 .../cassandra/cql3/SingleColumnRelation.java|   4 -
 .../cql3/restrictions/AbstractRestriction.java  |   4 +-
 .../restrictions/StatementRestrictions.java |  25 +-
 .../cql3/statements/SelectStatement.java|   8 +-
 .../db/index/SecondaryIndexManager.java |  43 +-
 .../entities/FrozenCollectionsTest.java |   4 +-
 .../validation/entities/SecondaryIndexTest.java |   2 +-
 .../cql3/validation/entities/UFAuthTest.java|  11 -
 .../entities/UFIdentificationTest.java  |   6 +-
 .../SelectMultiColumnRelationTest.java  |  31 +-
 .../SelectSingleColumnRelationTest.java |  34 +-
 .../cql3/validation/operations/SelectTest.java  | 829 ++-
 .../db/index/PerRowSecondaryIndexTest.java  |   4 +-
 14 files changed, 915 insertions(+), 92 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index db6d79d..5631a28 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
 2.2.6
+ * Fix filtering on non-primary key columns for thrift static column families
+   (CASSANDRA-6377)
  * Only log yaml config once, at startup (CASSANDRA-11217)
  * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
  * Reference leak with parallel repairs on the same table (CASSANDRA-11215)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
--
diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java 
b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
index b206631..dbae5f0 100644
--- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
+++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
@@ -196,10 +196,6 @@ public final class SingleColumnRelation extends Relation
 {
 ColumnSpecification receiver = columnDef;
 
-checkFalse(columnDef.isCompactValue(),
-   "Predicates on the non-primary-key column (%s) of a COMPACT 
table are not yet supported",
-   columnDef.name);
-
 if (isIN())
 {
 // We only allow IN on the row key and the clustering key so far, 
never on non-PK columns, and this even if

http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java 
b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
index dac7203..385bfbc 100644
--- a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
+++ b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
@@ -93,8 +93,8 @@ abstract class AbstractRestriction  implements Restriction
  ByteBuffer value)
  throws 
InvalidRequestException
 {
-checkNotNull(value, "Unsupported null value for indexed column %s", 
columnSpec.name);
-checkBindValueSet(value, "Unsupported unset value for indexed column 
%s", columnSpec.name);
+checkNotNull(value, "Unsupported null value for column %s", 
columnSpec.name);
+checkBindValueSet(value, "Unsupported unset value for column %s", 
columnSpec.name);
 checkFalse(value.remaining() > 0x, "Index expression values may 
not be larger than 64K");
 return value;
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java 
b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
index 

[5/6] cassandra git commit: Fix filtering on non-primary key columns for queries without index

[blerer]

Fix filtering on non-primary key columns for queries without index

patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377


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

Branch: refs/heads/cassandra-3.5
Commit: 9c3855b5fd83b9fa9ffb2e5495e43cbea9855dee
Parents: e01c6dd
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:09:54 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:09:54 2016 +0100

--
 CHANGES.txt |1 +
 .../cassandra/cql3/SingleColumnRelation.java|4 -
 .../restrictions/StatementRestrictions.java |8 +-
 .../cql3/statements/SelectStatement.java|   11 +-
 .../apache/cassandra/db/filter/RowFilter.java   |   51 +-
 .../index/internal/CassandraIndex.java  |   15 +
 .../entities/FrozenCollectionsTest.java |3 +-
 .../validation/entities/SecondaryIndexTest.java |3 +-
 .../cql3/validation/operations/DeleteTest.java  |   10 +-
 .../SelectMultiColumnRelationTest.java  |   54 +-
 .../SelectSingleColumnRelationTest.java |   51 +-
 .../cql3/validation/operations/SelectTest.java  | 1071 +-
 .../cql3/validation/operations/UpdateTest.java  |8 +-
 .../apache/cassandra/index/CustomIndexTest.java |4 +-
 .../index/internal/CassandraIndexTest.java  |   34 +-
 15 files changed, 1205 insertions(+), 123 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 520e66e..7204098 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.5
+ * Fix filtering on non-primary key columns for queries without index 
(CASSANDRA-6377)
  * Fix sstableloader fail when using materialized view (CASSANDRA-11275)
 Merged from 2.2:
  * Only log yaml config once, at startup (CASSANDRA-11217)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
--
diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java 
b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
index e2c0b79..05ba42d 100644
--- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
+++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
@@ -227,10 +227,6 @@ public final class SingleColumnRelation extends Relation
 {
 ColumnSpecification receiver = columnDef;
 
-checkFalse(!columnDef.isPrimaryKeyColumn() && isDense,
-   "Predicates on the non-primary-key column (%s) of a COMPACT 
table are not yet supported",
-   columnDef.name);
-
 if (isIN())
 {
 // We only allow IN on the row key and the clustering key so far, 
never on non-PK columns, and this even if

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java 
b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
index 1c7db4e..797b8e4 100644
--- a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
+++ b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
@@ -50,8 +50,10 @@ import static 
org.apache.cassandra.cql3.statements.RequestValidations.invalidReq
  */
 public final class StatementRestrictions
 {
-public static final String NO_INDEX_FOUND_MESSAGE =
-"No supported secondary index found for the non primary key columns 
restrictions";
+public static final String REQUIRES_ALLOW_FILTERING_MESSAGE =
+"Cannot execute this query as it might involve data filtering and 
" +
+"thus may have unpredictable performance. If you want to execute " 
+
+"this query despite the performance unpredictability, use ALLOW 
FILTERING";
 
 /**
  * The type of statement
@@ -224,7 +226,7 @@ public final class StatementRestrictions
 if (hasQueriableIndex)
 usesSecondaryIndexing = true;
 else if (!useFiltering)
-throw invalidRequest(NO_INDEX_FOUND_MESSAGE);
+throw 
invalidRequest(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE);
 
 indexRestrictions.add(nonPrimaryKeyRestrictions);
 }

[4/6] cassandra git commit: Fix filtering on non-primary key columns for queries without index

[blerer]

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java 
b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
index 8622c98..a7eeeb8 100644
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
@@ -24,6 +24,8 @@ import org.junit.Test;
 
 import junit.framework.Assert;
 import org.apache.cassandra.cql3.UntypedResultSet;
+import org.apache.cassandra.cql3.restrictions.StatementRestrictions;
+import org.apache.cassandra.utils.ByteBufferUtil;
 import org.apache.cassandra.cql3.CQLTester;
 
 import static org.junit.Assert.assertEquals;
@@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue;
  */
 public class SelectTest extends CQLTester
 {
+private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65);
+
 @Test
 public void testSingleClustering() throws Throwable
 {
@@ -366,7 +370,7 @@ public class SelectTest extends CQLTester
 }
 
 @Test
-public void testSetContains() throws Throwable
+public void testSetContainsWithIndex() throws Throwable
 {
 createTable("CREATE TABLE %s (account text, id int, categories 
set, PRIMARY KEY (account, id))");
 createIndex("CREATE INDEX ON %s(categories)");
@@ -387,19 +391,19 @@ public class SelectTest extends CQLTester
row("test", 5, set("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND 
categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories 
CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", 
"notPresent"));
 }
 
 @Test
-public void testListContains() throws Throwable
+public void testListContainsWithIndex() throws Throwable
 {
 createTable("CREATE TABLE %s (account text, id int, categories 
list, PRIMARY KEY (account, id))");
 createIndex("CREATE INDEX ON %s(categories)");
@@ -420,13 +424,13 @@ public class SelectTest extends CQLTester
row("test", 5, list("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ? AND categories CONTAINS ?",
  "test", 5, "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND 
categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING",
@@ -434,7 +438,7 @@ public class SelectTest extends CQLTester
 }
 
 @Test
-public void testListContainsWithFiltering() throws Throwable
+public void testListContainsWithIndexAndFiltering() throws Throwable
 {
 createTable("CREATE TABLE %s (e int PRIMARY KEY, f list, s 
int)");
 createIndex("CREATE INDEX ON %s(f)");
@@ -452,7 +456,7 @@ public class SelectTest extends CQLTester
 

[6/6] cassandra git commit: Merge branch cassandra-3.0 into cassandra-3.5

[blerer]

Merge branch cassandra-3.0 into cassandra-3.5


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

Branch: refs/heads/cassandra-3.5
Commit: 8c83c8edab4f1c23c382bb0ac076cab44d5f4dda
Parents: a8dc14d 9c3855b
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:12:33 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:13:35 2016 +0100

--
 CHANGES.txt |1 +
 .../cassandra/cql3/SingleColumnRelation.java|4 -
 .../restrictions/StatementRestrictions.java |   25 +-
 .../cql3/statements/SelectStatement.java|   12 +-
 .../apache/cassandra/db/filter/RowFilter.java   |   50 +-
 .../index/internal/CassandraIndex.java  |   23 +-
 .../entities/FrozenCollectionsTest.java |3 +-
 .../validation/entities/SecondaryIndexTest.java |3 +-
 .../cql3/validation/operations/DeleteTest.java  |   10 +-
 .../SelectMultiColumnRelationTest.java  |   54 +-
 .../SelectSingleColumnRelationTest.java |   51 +-
 .../cql3/validation/operations/SelectTest.java  | 1063 +-
 .../cql3/validation/operations/UpdateTest.java  |8 +-
 .../apache/cassandra/index/CustomIndexTest.java |4 +-
 .../index/internal/CassandraIndexTest.java  |   34 +-
 15 files changed, 1199 insertions(+), 146 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/CHANGES.txt
--
diff --cc CHANGES.txt
index a6cae21,7204098..4c21d66
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,5 -1,5 +1,6 @@@
 -3.0.5
 +3.5
 +Merged from 3.0:
+  * Fix filtering on non-primary key columns for queries without index 
(CASSANDRA-6377)
   * Fix sstableloader fail when using materialized view (CASSANDRA-11275)
  Merged from 2.2:
   * Only log yaml config once, at startup (CASSANDRA-11217)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --cc src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index d3a79d0,51d675b..2f4d468
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@@ -702,9 -696,8 +696,7 @@@ public class SelectStatement implement
  // we want to include static columns and we're done.
  if (!partition.hasNext())
  {
- if (!staticRow.isEmpty()
- && (!restrictions.hasClusteringColumnsRestriction() || 
cfm.isStaticCompactTable())
- && !restrictions.hasRegularColumnsRestriction())
 -if (!staticRow.isEmpty() && 
(!restrictions.usesSecondaryIndexing() || cfm.isStaticCompactTable())
 -&& !restrictions.hasClusteringColumnsRestriction())
++if (!staticRow.isEmpty() && 
(!restrictions.hasClusteringColumnsRestriction() || cfm.isStaticCompactTable()))
  {
  result.newRow(protocolVersion);
  for (ColumnDefinition def : selection.getColumns())

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/db/filter/RowFilter.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c83c8ed/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
--
diff --cc src/java/org/apache/cassandra/index/internal/CassandraIndex.java
index f503e59,74d3f5d..c3e75e0
--- a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
+++ b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
@@@ -5,12 -5,13 +5,11 @@@ import java.util.*
  import java.util.concurrent.Callable;
  import java.util.concurrent.Future;
  import java.util.function.BiFunction;
 -import java.util.regex.Matcher;
--import java.util.regex.Pattern;
  import java.util.stream.Collectors;
  import java.util.stream.StreamSupport;
  
  import com.google.common.collect.ImmutableSet;
- import org.apache.cassandra.index.TargetParser;
 -import 

[3/6] cassandra git commit: Merge branch cassandra-2.2 into cassandra-3.0

[blerer]

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/e01c6dd3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e01c6dd3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e01c6dd3

Branch: refs/heads/cassandra-3.5
Commit: e01c6dd3aae90c9eeb4fce7d8dd18123f02fed48
Parents: 19bccb4 90fd8de
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:07:23 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:07:35 2016 +0100

--

--

[1/6] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.5 a8dc14d74 -> 8c83c8eda


http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java 
b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
index 506bdaf..d8cd3c3 100644
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
@@ -24,6 +24,8 @@ import org.junit.Test;
 
 import junit.framework.Assert;
 import org.apache.cassandra.cql3.UntypedResultSet;
+import org.apache.cassandra.cql3.restrictions.StatementRestrictions;
+import org.apache.cassandra.utils.ByteBufferUtil;
 import org.apache.cassandra.cql3.CQLTester;
 
 import static org.junit.Assert.assertEquals;
@@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue;
  */
 public class SelectTest extends CQLTester
 {
+private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65);
+
 @Test
 public void testSingleClustering() throws Throwable
 {
@@ -387,13 +391,13 @@ public class SelectTest extends CQLTester
row("test", 5, set("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND 
categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories 
CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", 
"notPresent"));
 }
@@ -420,13 +424,13 @@ public class SelectTest extends CQLTester
row("test", 5, list("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ? AND categories CONTAINS ?",
  "test", 5, "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND 
categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING",
@@ -472,19 +476,19 @@ public class SelectTest extends CQLTester
row("test", 5, map("lmn", "foo"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS KEY ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS KEY ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+

[2/2] cassandra git commit: Fix filtering on non-primary key columns for queries without index

[blerer]

Fix filtering on non-primary key columns for queries without index

patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377


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

Branch: refs/heads/cassandra-3.0
Commit: 9c3855b5fd83b9fa9ffb2e5495e43cbea9855dee
Parents: e01c6dd
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:09:54 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:09:54 2016 +0100

--
 CHANGES.txt |1 +
 .../cassandra/cql3/SingleColumnRelation.java|4 -
 .../restrictions/StatementRestrictions.java |8 +-
 .../cql3/statements/SelectStatement.java|   11 +-
 .../apache/cassandra/db/filter/RowFilter.java   |   51 +-
 .../index/internal/CassandraIndex.java  |   15 +
 .../entities/FrozenCollectionsTest.java |3 +-
 .../validation/entities/SecondaryIndexTest.java |3 +-
 .../cql3/validation/operations/DeleteTest.java  |   10 +-
 .../SelectMultiColumnRelationTest.java  |   54 +-
 .../SelectSingleColumnRelationTest.java |   51 +-
 .../cql3/validation/operations/SelectTest.java  | 1071 +-
 .../cql3/validation/operations/UpdateTest.java  |8 +-
 .../apache/cassandra/index/CustomIndexTest.java |4 +-
 .../index/internal/CassandraIndexTest.java  |   34 +-
 15 files changed, 1205 insertions(+), 123 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 520e66e..7204098 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.5
+ * Fix filtering on non-primary key columns for queries without index 
(CASSANDRA-6377)
  * Fix sstableloader fail when using materialized view (CASSANDRA-11275)
 Merged from 2.2:
  * Only log yaml config once, at startup (CASSANDRA-11217)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
--
diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java 
b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
index e2c0b79..05ba42d 100644
--- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
+++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
@@ -227,10 +227,6 @@ public final class SingleColumnRelation extends Relation
 {
 ColumnSpecification receiver = columnDef;
 
-checkFalse(!columnDef.isPrimaryKeyColumn() && isDense,
-   "Predicates on the non-primary-key column (%s) of a COMPACT 
table are not yet supported",
-   columnDef.name);
-
 if (isIN())
 {
 // We only allow IN on the row key and the clustering key so far, 
never on non-PK columns, and this even if

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java 
b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
index 1c7db4e..797b8e4 100644
--- a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
+++ b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
@@ -50,8 +50,10 @@ import static 
org.apache.cassandra.cql3.statements.RequestValidations.invalidReq
  */
 public final class StatementRestrictions
 {
-public static final String NO_INDEX_FOUND_MESSAGE =
-"No supported secondary index found for the non primary key columns 
restrictions";
+public static final String REQUIRES_ALLOW_FILTERING_MESSAGE =
+"Cannot execute this query as it might involve data filtering and 
" +
+"thus may have unpredictable performance. If you want to execute " 
+
+"this query despite the performance unpredictability, use ALLOW 
FILTERING";
 
 /**
  * The type of statement
@@ -224,7 +226,7 @@ public final class StatementRestrictions
 if (hasQueriableIndex)
 usesSecondaryIndexing = true;
 else if (!useFiltering)
-throw invalidRequest(NO_INDEX_FOUND_MESSAGE);
+throw 
invalidRequest(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE);
 
 indexRestrictions.add(nonPrimaryKeyRestrictions);
 }

[1/2] cassandra git commit: Fix filtering on non-primary key columns for queries without index

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 e01c6dd3a -> 9c3855b5f


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c3855b5/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java 
b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
index 8622c98..a7eeeb8 100644
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
@@ -24,6 +24,8 @@ import org.junit.Test;
 
 import junit.framework.Assert;
 import org.apache.cassandra.cql3.UntypedResultSet;
+import org.apache.cassandra.cql3.restrictions.StatementRestrictions;
+import org.apache.cassandra.utils.ByteBufferUtil;
 import org.apache.cassandra.cql3.CQLTester;
 
 import static org.junit.Assert.assertEquals;
@@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue;
  */
 public class SelectTest extends CQLTester
 {
+private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65);
+
 @Test
 public void testSingleClustering() throws Throwable
 {
@@ -366,7 +370,7 @@ public class SelectTest extends CQLTester
 }
 
 @Test
-public void testSetContains() throws Throwable
+public void testSetContainsWithIndex() throws Throwable
 {
 createTable("CREATE TABLE %s (account text, id int, categories 
set, PRIMARY KEY (account, id))");
 createIndex("CREATE INDEX ON %s(categories)");
@@ -387,19 +391,19 @@ public class SelectTest extends CQLTester
row("test", 5, set("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND 
categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories 
CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", 
"notPresent"));
 }
 
 @Test
-public void testListContains() throws Throwable
+public void testListContainsWithIndex() throws Throwable
 {
 createTable("CREATE TABLE %s (account text, id int, categories 
list, PRIMARY KEY (account, id))");
 createIndex("CREATE INDEX ON %s(categories)");
@@ -420,13 +424,13 @@ public class SelectTest extends CQLTester
row("test", 5, list("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ? AND categories CONTAINS ?",
  "test", 5, "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND 
categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING",
@@ -434,7 +438,7 @@ public class SelectTest extends CQLTester
 }
 
 @Test
-public void testListContainsWithFiltering() throws Throwable
+public void testListContainsWithIndexAndFiltering() throws Throwable
 {
 createTable("CREATE TABLE %s (e int PRIMARY KEY, f list, s 
int)");
 

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

[blerer]

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/e01c6dd3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e01c6dd3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e01c6dd3

Branch: refs/heads/cassandra-3.0
Commit: e01c6dd3aae90c9eeb4fce7d8dd18123f02fed48
Parents: 19bccb4 90fd8de
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:07:23 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:07:35 2016 +0100

--

--

[1/3] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 19bccb4ea -> e01c6dd3a


http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java 
b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
index 506bdaf..d8cd3c3 100644
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
@@ -24,6 +24,8 @@ import org.junit.Test;
 
 import junit.framework.Assert;
 import org.apache.cassandra.cql3.UntypedResultSet;
+import org.apache.cassandra.cql3.restrictions.StatementRestrictions;
+import org.apache.cassandra.utils.ByteBufferUtil;
 import org.apache.cassandra.cql3.CQLTester;
 
 import static org.junit.Assert.assertEquals;
@@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue;
  */
 public class SelectTest extends CQLTester
 {
+private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65);
+
 @Test
 public void testSingleClustering() throws Throwable
 {
@@ -387,13 +391,13 @@ public class SelectTest extends CQLTester
row("test", 5, set("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND 
categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories 
CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", 
"notPresent"));
 }
@@ -420,13 +424,13 @@ public class SelectTest extends CQLTester
row("test", 5, list("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ? AND categories CONTAINS ?",
  "test", 5, "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND 
categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING",
@@ -472,19 +476,19 @@ public class SelectTest extends CQLTester
row("test", 5, map("lmn", "foo"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS KEY ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS KEY ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+

[2/3] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families

[blerer]

Fix filtering on non-primary key columns for thrift static column families

patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377


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

Branch: refs/heads/cassandra-3.0
Commit: 90fd8deed0d1eaa12906bc80aaf54daf837f3a81
Parents: 0934542
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:05:13 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:05:13 2016 +0100

--
 CHANGES.txt |   2 +
 .../cassandra/cql3/SingleColumnRelation.java|   4 -
 .../cql3/restrictions/AbstractRestriction.java  |   4 +-
 .../restrictions/StatementRestrictions.java |  25 +-
 .../cql3/statements/SelectStatement.java|   8 +-
 .../db/index/SecondaryIndexManager.java |  43 +-
 .../entities/FrozenCollectionsTest.java |   4 +-
 .../validation/entities/SecondaryIndexTest.java |   2 +-
 .../cql3/validation/entities/UFAuthTest.java|  11 -
 .../entities/UFIdentificationTest.java  |   6 +-
 .../SelectMultiColumnRelationTest.java  |  31 +-
 .../SelectSingleColumnRelationTest.java |  34 +-
 .../cql3/validation/operations/SelectTest.java  | 829 ++-
 .../db/index/PerRowSecondaryIndexTest.java  |   4 +-
 14 files changed, 915 insertions(+), 92 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index db6d79d..5631a28 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
 2.2.6
+ * Fix filtering on non-primary key columns for thrift static column families
+   (CASSANDRA-6377)
  * Only log yaml config once, at startup (CASSANDRA-11217)
  * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
  * Reference leak with parallel repairs on the same table (CASSANDRA-11215)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
--
diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java 
b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
index b206631..dbae5f0 100644
--- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
+++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
@@ -196,10 +196,6 @@ public final class SingleColumnRelation extends Relation
 {
 ColumnSpecification receiver = columnDef;
 
-checkFalse(columnDef.isCompactValue(),
-   "Predicates on the non-primary-key column (%s) of a COMPACT 
table are not yet supported",
-   columnDef.name);
-
 if (isIN())
 {
 // We only allow IN on the row key and the clustering key so far, 
never on non-PK columns, and this even if

http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java 
b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
index dac7203..385bfbc 100644
--- a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
+++ b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
@@ -93,8 +93,8 @@ abstract class AbstractRestriction  implements Restriction
  ByteBuffer value)
  throws 
InvalidRequestException
 {
-checkNotNull(value, "Unsupported null value for indexed column %s", 
columnSpec.name);
-checkBindValueSet(value, "Unsupported unset value for indexed column 
%s", columnSpec.name);
+checkNotNull(value, "Unsupported null value for column %s", 
columnSpec.name);
+checkBindValueSet(value, "Unsupported unset value for column %s", 
columnSpec.name);
 checkFalse(value.remaining() > 0x, "Index expression values may 
not be larger than 64K");
 return value;
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java 
b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
index 

[1/2] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 093454205 -> 90fd8deed


http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java 
b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
index 506bdaf..d8cd3c3 100644
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
@@ -24,6 +24,8 @@ import org.junit.Test;
 
 import junit.framework.Assert;
 import org.apache.cassandra.cql3.UntypedResultSet;
+import org.apache.cassandra.cql3.restrictions.StatementRestrictions;
+import org.apache.cassandra.utils.ByteBufferUtil;
 import org.apache.cassandra.cql3.CQLTester;
 
 import static org.junit.Assert.assertEquals;
@@ -34,6 +36,8 @@ import static org.junit.Assert.assertTrue;
  */
 public class SelectTest extends CQLTester
 {
+private static final ByteBuffer TOO_BIG = ByteBuffer.allocate(1024 * 65);
+
 @Test
 public void testSingleClustering() throws Throwable
 {
@@ -387,13 +391,13 @@ public class SelectTest extends CQLTester
row("test", 5, set("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND 
categories CONTAINS ? AND categories CONTAINS ?", "xyz", "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND categories 
CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING", "xyz", "lmn", 
"notPresent"));
 }
@@ -420,13 +424,13 @@ public class SelectTest extends CQLTester
row("test", 5, list("lmn"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+
assertInvalidMessage(StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE,
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS ? AND categories CONTAINS ?",
  "test", 5, "lmn", "notPresent");
 assertEmpty(execute("SELECT * FROM %s WHERE account = ? AND id = ? AND 
categories CONTAINS ? AND categories CONTAINS ? ALLOW FILTERING",
@@ -472,19 +476,19 @@ public class SelectTest extends CQLTester
row("test", 5, map("lmn", "foo"))
 );
 
-assertInvalidMessage("Unsupported null value for indexed column 
categories",
+assertInvalidMessage("Unsupported null value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS KEY ?", "test", 5, null);
 
-assertInvalidMessage("Unsupported unset value for indexed column 
categories",
+assertInvalidMessage("Unsupported unset value for column categories",
  "SELECT * FROM %s WHERE account = ? AND id = ? 
AND categories CONTAINS KEY ?", "test", 5, unset());
 
-assertInvalidMessage("Cannot execute this query as it might involve 
data filtering and thus may have unpredictable performance. If you want to 
execute this query despite the performance unpredictability, use ALLOW 
FILTERING",
+

[2/2] cassandra git commit: Fix filtering on non-primary key columns for thrift static column families

[blerer]

Fix filtering on non-primary key columns for thrift static column families

patch by Benjamin Lerer; reviewed by Sam Tunnicliffe for CASSANDRA-6377


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

Branch: refs/heads/cassandra-2.2
Commit: 90fd8deed0d1eaa12906bc80aaf54daf837f3a81
Parents: 0934542
Author: Benjamin Lerer 
Authored: Fri Mar 4 22:05:13 2016 +0100
Committer: Benjamin Lerer 
Committed: Fri Mar 4 22:05:13 2016 +0100

--
 CHANGES.txt |   2 +
 .../cassandra/cql3/SingleColumnRelation.java|   4 -
 .../cql3/restrictions/AbstractRestriction.java  |   4 +-
 .../restrictions/StatementRestrictions.java |  25 +-
 .../cql3/statements/SelectStatement.java|   8 +-
 .../db/index/SecondaryIndexManager.java |  43 +-
 .../entities/FrozenCollectionsTest.java |   4 +-
 .../validation/entities/SecondaryIndexTest.java |   2 +-
 .../cql3/validation/entities/UFAuthTest.java|  11 -
 .../entities/UFIdentificationTest.java  |   6 +-
 .../SelectMultiColumnRelationTest.java  |  31 +-
 .../SelectSingleColumnRelationTest.java |  34 +-
 .../cql3/validation/operations/SelectTest.java  | 829 ++-
 .../db/index/PerRowSecondaryIndexTest.java  |   4 +-
 14 files changed, 915 insertions(+), 92 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index db6d79d..5631a28 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
 2.2.6
+ * Fix filtering on non-primary key columns for thrift static column families
+   (CASSANDRA-6377)
  * Only log yaml config once, at startup (CASSANDRA-11217)
  * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
  * Reference leak with parallel repairs on the same table (CASSANDRA-11215)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
--
diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java 
b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
index b206631..dbae5f0 100644
--- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
+++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
@@ -196,10 +196,6 @@ public final class SingleColumnRelation extends Relation
 {
 ColumnSpecification receiver = columnDef;
 
-checkFalse(columnDef.isCompactValue(),
-   "Predicates on the non-primary-key column (%s) of a COMPACT 
table are not yet supported",
-   columnDef.name);
-
 if (isIN())
 {
 // We only allow IN on the row key and the clustering key so far, 
never on non-PK columns, and this even if

http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java 
b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
index dac7203..385bfbc 100644
--- a/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
+++ b/src/java/org/apache/cassandra/cql3/restrictions/AbstractRestriction.java
@@ -93,8 +93,8 @@ abstract class AbstractRestriction  implements Restriction
  ByteBuffer value)
  throws 
InvalidRequestException
 {
-checkNotNull(value, "Unsupported null value for indexed column %s", 
columnSpec.name);
-checkBindValueSet(value, "Unsupported unset value for indexed column 
%s", columnSpec.name);
+checkNotNull(value, "Unsupported null value for column %s", 
columnSpec.name);
+checkBindValueSet(value, "Unsupported unset value for column %s", 
columnSpec.name);
 checkFalse(value.remaining() > 0x, "Index expression values may 
not be larger than 64K");
 return value;
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/90fd8dee/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java 
b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
index 

[jira] [Commented] (CASSANDRA-9967) Determine if a Materialized View is finished building, without having to query each node

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-9967:
--

Sorry for the delay.

utests and dtests look clean compared to upstream. The added dtests pass 
locally for me. A dtest that covers calling the command after dropping a view 
would be nice.

In SystemKeyspace
- Now might be a good time to fix the comment above {{finishViewBuildStatus}} 
that we discussed ("the build succeeded, but the view build failed")
- Changing {{viewBuiltReplicated}} to {{setViewBuiltReplicated}} better matches 
the naming convention used elsewhere in the class
- The {{forceBlockingFlush}} at end of {{viewBuiltReplicated}} is redundant 
with the call at the end of {{setViewBuilt}}

In QueryProcessor
- As we discussed, there's other improvements to be made in QueryProcessor for 
clarity. It seems to me that the {{executeInternal}} you added might not be 
appropriately named - it calls {{statement.execute}} rather than 
{{statement.executeInternal}}. (It's not entirely clear whether the internal in 
QueryProcessor.executeInternal is to reflect that it uses internal QueryState 
or executeInternal on PreparedStatement, but it seems to me to indicate the 
latter.)

In StorageService
- In {{getViewBuildStatuses}}, retrieving the {{hostIdToEndpoint}} map at a 
different time than calling {{getEndpointToHostIdMapForReading()}} opens up a 
race with changes in TokenMetadata that could result in the endpoint being 
null. It seems to me cleaner to retrieve the endpointToHostIdMapForReading and 
iterate over its entries rather than maintaining two separate maps.

> Determine if a Materialized View is finished building, without having to 
> query each node
> 
>
> Key: CASSANDRA-9967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9967
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Alan Boudreault
>Assignee: Carl Yeksigian
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
>
> Since MVs are eventually consistent with its base table, It would nice if we 
> could easily know the state of the MV after its creation, so we could wait 
> until the MV is built before doing some operations.
> // cc [~mbroecheler] [~tjake] [~carlyeks] [~enigmacurry]



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

[jira] [Commented] (CASSANDRA-9117) LEAK DETECTED during repair, startup

[Sebastian Estevez (JIRA)]

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

Sebastian Estevez commented on CASSANDRA-9117:
--

For future reference I ended up openning CASSANDRA-10079 and it's fixed in 
2.1.12

> LEAK DETECTED during repair, startup
> 
>
> Key: CASSANDRA-9117
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9117
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tyler Hobbs
>Assignee: Marcus Eriksson
> Fix For: 2.2.0 beta 1
>
> Attachments: 
> 0001-dont-initialize-writer-before-checking-if-iter-is-em.patch, node1.log, 
> node2.log.gz
>
>
> When running the 
> {{incremental_repair_test.TestIncRepair.multiple_repair_test}} dtest, the 
> following error logs show up:
> {noformat}
> ERROR [Reference-Reaper:1] 2015-04-03 15:48:25,491 Ref.java:181 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@83f047e) to class 
> org.apache.cassandra.io.util.SafeMemory$MemoryTidy@1631580268:Memory@[7f354800bdc0..7f354800bde8)
>  was not released before the reference was garbage collected
> ERROR [Reference-Reaper:1] 2015-04-03 15:48:25,493 Ref.java:181 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@50bc8f67) to class 
> org.apache.cassandra.io.util.SafeMemory$MemoryTidy@191552666:Memory@[7f354800ba90..7f354800bdb0)
>  was not released before the reference was garbage collected
> ERROR [Reference-Reaper:1] 2015-04-03 15:48:25,493 Ref.java:181 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@7fd10877) to class 
> org.apache.cassandra.io.util.SafeMemory$MemoryTidy@1954741807:Memory@[7f3548101190..7f3548101194)
>  was not released before the reference was garbage collected
> ERROR [Reference-Reaper:1] 2015-04-03 15:48:25,494 Ref.java:181 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@578550ac) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$1@1903393047:[[OffHeapBitSet]]
>  was not released before the reference was garbage collected
> {noformat}
> The test is being run against trunk (commit {{1dff098e}}).  I've attached a 
> DEBUG-level log from the test run.



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

[jira] [Commented] (CASSANDRA-6377) ALLOW FILTERING should allow seq scan filtering

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-6377:
---

As filtering on non primary-key columns for queries without secondary index was 
already supported since 3.0 (as a side effect of CASSANDRA-8099) and the 
patches for 3.0 and 3.x mostly fixes some issues with validation and filtering 
on static columns. I think it is best to push the patches into {{3.0.5}} and 
{{3.5}}. 


> ALLOW FILTERING should allow seq scan filtering
> ---
>
> Key: CASSANDRA-6377
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6377
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Benjamin Lerer
>  Labels: cql
> Fix For: 3.0.x, 3.x
>
>
> CREATE TABLE emp_table2 (
> empID int PRIMARY KEY,
> firstname text,
> lastname text,
> b_mon text,
> b_day text,
> b_yr text,
> );
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (100,'jane','doe','oct','31','1980');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (101,'john','smith','jan','01','1981');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (102,'mary','jones','apr','15','1982');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (103,'tim','best','oct','25','1982');
>
> SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2 
> WHERE b_mon='oct' ALLOW FILTERING;
> Bad Request: No indexed columns present in by-columns clause with Equal 
> operator



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

[jira] [Commented] (CASSANDRA-7928) Digest queries do not require alder32 checks

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-7928:
--

Sure close it. 

> Digest queries do not require alder32 checks
> 
>
> Key: CASSANDRA-7928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7928
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Priority: Minor
>  Labels: performance
> Fix For: 3.x
>
>
>  While reading data from sstables, C* does Alder32 checks for any data being 
> read. We have seen that this causes higher CPU usage while doing kernel 
> profiling. These checks might not be useful for digest queries as they will 
> have a different digest in case of corruption. 
>  



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

[jira] [Commented] (CASSANDRA-11210) Unresolved hostname in replace address

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-11210:
---

+1. 

> Unresolved hostname in replace address
> --
>
> Key: CASSANDRA-11210
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11210
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jan Karlsson
>Priority: Minor
>  Labels: lhf
> Fix For: 2.2.6
>
> Attachments: 
> 0001-Unresolved-hostname-leads-to-replace-being-ignored.patch
>
>
> If you provide a hostname which could not be resolved by DNS, it leads to 
> replace args being ignored. If you provide an IP which is not in the cluster, 
> it does the right thing and complain.



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

[jira] [Updated] (CASSANDRA-11210) Unresolved hostname in replace address

[sankalp kohli (JIRA)]

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

sankalp kohli updated CASSANDRA-11210:
--
Status: Ready to Commit  (was: Patch Available)

> Unresolved hostname in replace address
> --
>
> Key: CASSANDRA-11210
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11210
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jan Karlsson
>Priority: Minor
>  Labels: lhf
> Fix For: 2.2.6
>
> Attachments: 
> 0001-Unresolved-hostname-leads-to-replace-being-ignored.patch
>
>
> If you provide a hostname which could not be resolved by DNS, it leads to 
> replace args being ignored. If you provide an IP which is not in the cluster, 
> it does the right thing and complain.



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

[jira] [Updated] (CASSANDRA-11210) Unresolved hostname in replace address

[sankalp kohli (JIRA)]

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

sankalp kohli updated CASSANDRA-11210:
--
Reviewer: sankalp kohli

> Unresolved hostname in replace address
> --
>
> Key: CASSANDRA-11210
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11210
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jan Karlsson
>Priority: Minor
>  Labels: lhf
> Fix For: 2.2.6
>
> Attachments: 
> 0001-Unresolved-hostname-leads-to-replace-being-ignored.patch
>
>
> If you provide a hostname which could not be resolved by DNS, it leads to 
> replace args being ignored. If you provide an IP which is not in the cluster, 
> it does the right thing and complain.



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

[jira] [Created] (CASSANDRA-11306) Add support for ALTER INDEX command

[Jacques-Henri Berthemet (JIRA)]

Jacques-Henri Berthemet created CASSANDRA-11306:
---

 Summary: Add support for ALTER INDEX command
 Key: CASSANDRA-11306
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11306
 Project: Cassandra
  Issue Type: Wish
  Components: Core, CQL
 Environment: Cassandra 2.2+
Reporter: Jacques-Henri Berthemet


Cassandra supports  passing options to a (custom) secondary index at creation 
time:
https://docs.datastax.com/en/cql/3.1/cql/cql_reference/create_index_r.html
{code}
CREATE CUSTOM INDEX ON users (email) USING 'path.to.the.IndexClass' WITH 
OPTIONS = {'storage': '/mnt/ssd/indexes/'};
{code}

However it is not possible to update the options for an existing index.

It would be great to have an ALTER INDEX command similar to the ALTER TABLE 
command. Custom index implementation would receive the command and act 
accordingly.



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

[jira] [Updated] (CASSANDRA-11210) Unresolved hostname in replace address

[Jan Karlsson (JIRA)]

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

Jan Karlsson updated CASSANDRA-11210:
-
Attachment: 0001-Unresolved-hostname-leads-to-replace-being-ignored.patch

> Unresolved hostname in replace address
> --
>
> Key: CASSANDRA-11210
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11210
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jan Karlsson
>Priority: Minor
>  Labels: lhf
> Fix For: 2.2.6
>
> Attachments: 
> 0001-Unresolved-hostname-leads-to-replace-being-ignored.patch
>
>
> If you provide a hostname which could not be resolved by DNS, it leads to 
> replace args being ignored. If you provide an IP which is not in the cluster, 
> it does the right thing and complain.



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

[jira] [Updated] (CASSANDRA-11092) EXPAND breaks when the result has 0 rows in cqlsh

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11092:

Reviewer: Tyler Hobbs

> EXPAND breaks when the result has 0 rows in cqlsh
> -
>
> Key: CASSANDRA-11092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11092
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Kishan Karunaratne
>Assignee: Yuki Morishita
>Priority: Trivial
>  Labels: cqlsh
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> {noformat}
> cqlsh> EXPAND ON;
> Now Expanded output is enabled
> cqlsh> select * from system.local;
> @ Row 1
> -+-
>  key | local
>  bootstrapped| COMPLETED
>  broadcast_address   | 127.0.0.1
>  cluster_name| dse_50_graph
>  cql_version | 3.4.0
>  data_center | Graph
>  dse_version | 5.0.0
>  gossip_generation   | 1454032824
>  graph   | True
>  host_id | ad30ccb2-04a1-4511-98b6-a72e4ea182c0
>  listen_address  | 127.0.0.1
>  native_protocol_version | 4
>  partitioner | org.apache.cassandra.dht.Murmur3Partitioner
>  rack| rack1
>  release_version | 3.0.1.816
>  rpc_address | 127.0.0.1
>  schema_version  | 5667501a-4ac3-3f00-ab35-9040efb927ad
>  server_id   | A0-CE-C8-01-CC-CA
>  thrift_version  | 20.1.0
>  tokens  | {'-9223372036854775808'}
>  truncated_at| null
>  workload| Cassandra
> (1 rows)
> cqlsh> select * from system.peers;
> max() arg is an empty sequence
> cqlsh> EXPAND OFF;
> Disabled Expanded output.
> cqlsh> select * from system.peers;
>  peer | data_center | dse_version | graph | host_id | preferred_ip | rack | 
> release_version | rpc_address | schema_version | server_id | tokens | workload
> --+-+-+---+-+--+--+-+-++---++--
> (0 rows)
> {noformat}



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

[jira] [Updated] (CASSANDRA-11294) Provide better documentation for caching

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-11294:
-
Issue Type: Improvement  (was: Bug)

> Provide better documentation for caching
> 
>
> Key: CASSANDRA-11294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11294
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benjamin Lerer
>Priority: Minor
>
> I realized that the way caching works in C* is not properly documented. For 
> example the row cache will only be populated for single partition or 
> multi-partitions queries and not range queries. It will also never be 
> populated by secondary index queries even if they are single partition or 
> multi-partitions queries.
> The documentation should be improved to allow people to fully understand how 
> caching works.
>  



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

[jira] [Updated] (CASSANDRA-11210) Unresolved hostname in replace address

[Jan Karlsson (JIRA)]

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

Jan Karlsson updated CASSANDRA-11210:
-
Fix Version/s: 2.2.6
   Status: Patch Available  (was: Open)

This should apply cleanly to 3.0/trunk except for the Changelog.

> Unresolved hostname in replace address
> --
>
> Key: CASSANDRA-11210
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11210
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jan Karlsson
>Priority: Minor
>  Labels: lhf
> Fix For: 2.2.6
>
>
> If you provide a hostname which could not be resolved by DNS, it leads to 
> replace args being ignored. If you provide an IP which is not in the cluster, 
> it does the right thing and complain.



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

[jira] [Updated] (CASSANDRA-11295) Make custom filtering more extensible via custom classes

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-11295:
-
Reviewer: Sylvain Lebresne

> Make custom filtering more extensible via custom classes 
> -
>
> Key: CASSANDRA-11295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11295
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.x
>
>
> At the moment, the implementation of {{RowFilter.CustomExpression}} is 
> tightly bound to the syntax designed to support non-CQL search syntax for 
> custom 2i implementations. It might be interesting to decouple the two things 
> by making the custom expression implementation and serialization a bit more 
> pluggable. This would allow users to add their own custom expression 
> implementations to experiment with custom filtering strategies without having 
> to patch the C* source. As a minimally invasive first step, custom 
> expressions could be added programmatically via {{QueryHandler}}. Further 
> down the line, if this proves useful and we can figure out some reasonable 
> syntax we could think about adding the capability in CQL in a separate 
> ticket. 



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

[jira] [Updated] (CASSANDRA-11059) In cqlsh show static columns in a different color

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11059:

Reviewer: Yuki Morishita

> In cqlsh show static columns in a different color
> -
>
> Key: CASSANDRA-11059
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11059
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
> Environment: [cqlsh 5.0.1 | Cassandra 2.2.3 | CQL spec 3.3.1 | Native 
> protocol v4]
>Reporter: Cédric Hernalsteens
>Priority: Minor
> Fix For: 3.x
>
>
> The partition key columns are shown in red, the clustering columns in cyan, 
> it would be great to also distinguish between the static columns and the 
> other.



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

[jira] [Commented] (CASSANDRA-10707) Add support for Group By to Select statement

[Brian Hess (JIRA)]

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

 Brian Hess commented on CASSANDRA-10707:
-

A quick question/clarification on the GROUP BY and ORDER BY discussion from 
above.  The following are valid SQL:

{code:SQL}
SELECT pkey, ccol1, Max(x) As maxx FROM myTable GROUP BY pkey, ccol1 ORDER BY 
ccol1 pkey;
SELECT pkey, ccol1, Max(x) As maxx FROM myTable GROUP BY pkey, ccol1 ORDER BY 
maxx;
{code}

I think you are suggesting that the only real ordering that is allowed is the 
native ordering in the CQL tables.  Specifically, these 2 queries would not be 
supported.  Is that correct?

I think the logic is more like that the following CQL

{code:SQL}
SELECT pkey, ccol1 Max(x) AS maxx FROM myTable GROUP BY pkey, ccol1 ORDER BY 
pkey, ccol1
{code}

turns into

{code:SQL}
SELECT pkey, ccol1, Max(x) AS maxx FROM (
  SELECT pkey, ccol1, x FROM myTable ORDER BY pkey, ccol1
) AS sub1 GROUP BY pkey, ccol1;
{code}

That means that the ORDER BY clause must work in that inner query as valid CQL. 
 More generally:

{code:SQL}
SELECT [grouping columns], [aggregate function]([aggregate columns]) FROM 
[table] GROUP BY [grouping columns] ORDER BY [ordering columns]
{code}

Must satisfy the transformation to:

{code:SQL}
SELECT [grouping columns], [aggregate function]([aggregate columns]) FROM (
  SELECT [grouping columns], [aggregate columns] FROM [table] ORDER BY 
[ordering columns]
) AS sub1 GROUP BY [grouping columns]
{code}

And specifically that the inner sub-query is valid CQL, namely:

{code:SQL}
SELECT [grouping columns], [aggregate columns] FROM [table] ORDER BY [ordering 
columns]
{code}

That is certainly different than SQL, which does not have this restriction.  
I'm +0.5 on having the syntax be the same as SQL as I think it is slightly 
better than the alternative.  I'm just noting that the semantics really are a 
bit different and there are more restrictions with the ORDER BY clause in CQL 
with this ticket than in SQL.  That nuance needs to be called out in the 
documentation or folks will certainly run into the error.

I would also add that if someone uses an incorrect ORDER BY, the error should 
not only call out that it is an error, but also indicate what sorts of ORDER BY 
clauses are supported.

> Add support for Group By to Select statement
> 
>
> Key: CASSANDRA-10707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10707
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> Now that Cassandra support aggregate functions, it makes sense to support 
> {{GROUP BY}} on the {{SELECT}} statements.
> It should be possible to group either at the partition level or at the 
> clustering column level.
> {code}
> SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey;
> SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP 
> BY partitionKey, clustering0, clustering1; 
> {code}



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

[jira] [Comment Edited] (CASSANDRA-11302) Invalid time unit conversion causing write timeouts

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg edited comment on CASSANDRA-11302 at 3/4/16 3:07 PM:


Yes that is an issue. There is an isTimedOut method on QueuedMessage that could 
probably be made to do the conversion and be called from all the locations that 
want to check the timeout.

The attached patch would fix the bug, but I think we should put this in a 
helper so the next time the units change we only have to update one line.


was (Author: aweisberg):
Yes that is the issue. There is an isTimedOut method on QueuedMessage that 
could probably be made to do the conversion and be called from all the 
locations that want to check the timeout.

> Invalid time unit conversion causing write timeouts
> ---
>
> Key: CASSANDRA-11302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11302
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Mike Heffner
> Attachments: nanosec.patch
>
>
> We've been debugging a write timeout that we saw after upgrading from the 
> 2.0.x release line, with our particular workload. Details of that process can 
> be found in this thread:
> https://www.mail-archive.com/user@cassandra.apache.org/msg46064.html
> After bisecting various patch release versions, and then commits, on the 
> 2.1.x release line we've identified version 2.1.5 and this commit as the 
> point where the timeouts first start appearing:
> https://github.com/apache/cassandra/commit/828496492c51d7437b690999205ecc941f41a0a9
> After examining the commit we believe this line was a typo:
> https://github.com/apache/cassandra/commit/828496492c51d7437b690999205ecc941f41a0a9#diff-c7ef124561c4cde1c906f28ad3883a88L467
> as it doesn't properly convert the timeout value from milliseconds to 
> nanoseconds.
> After testing with the attached patch applied, we do not see timeouts on 
> version 2.1.5 nor against 2.2.5 when we bring the patch forward. While we've 
> tested our workload against this and we are fairly confident in the patch, we 
> are not experts with the code base so we would prefer additional review.



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

[jira] [Commented] (CASSANDRA-11302) Invalid time unit conversion causing write timeouts

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-11302:


Yes that is the issue. There is an isTimedOut method on QueuedMessage that 
could probably be made to do the conversion and be called from all the 
locations that want to check the timeout.

> Invalid time unit conversion causing write timeouts
> ---
>
> Key: CASSANDRA-11302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11302
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Mike Heffner
> Attachments: nanosec.patch
>
>
> We've been debugging a write timeout that we saw after upgrading from the 
> 2.0.x release line, with our particular workload. Details of that process can 
> be found in this thread:
> https://www.mail-archive.com/user@cassandra.apache.org/msg46064.html
> After bisecting various patch release versions, and then commits, on the 
> 2.1.x release line we've identified version 2.1.5 and this commit as the 
> point where the timeouts first start appearing:
> https://github.com/apache/cassandra/commit/828496492c51d7437b690999205ecc941f41a0a9
> After examining the commit we believe this line was a typo:
> https://github.com/apache/cassandra/commit/828496492c51d7437b690999205ecc941f41a0a9#diff-c7ef124561c4cde1c906f28ad3883a88L467
> as it doesn't properly convert the timeout value from milliseconds to 
> nanoseconds.
> After testing with the attached patch applied, we do not see timeouts on 
> version 2.1.5 nor against 2.2.5 when we bring the patch forward. While we've 
> tested our workload against this and we are fairly confident in the patch, we 
> are not experts with the code base so we would prefer additional review.



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

[jira] [Commented] (CASSANDRA-11304) Stack overflow when querying 2ndary index

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-11304:
--

For info, seems the recursive call to {{prepareNext}} that is the cause of this 
has already been fixed on trunk by CASSANDRA-10750 (which somehow doesn't have 
a proper fix version) but not on 3.0. We might just want to backport that 
change here.

> Stack overflow when querying 2ndary index
> -
>
> Key: CASSANDRA-11304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11304
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: 3 Node cluster / Ubuntu 14.04 / Cassandra 3.0.3
>Reporter: Job Tiel Groenestege
>Assignee: Sam Tunnicliffe
>
> When reading data through a secondary index _select * from tableName where 
> secIndexField = 'foo'_  (from a Java application) I get the following 
> stacktrace on all nodes; after the query read fails. It happens repeatably 
> when  I rerun the same query:
> {quote}
> WARN  [SharedPool-Worker-8] 2016-03-04 13:26:28,041 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-8,5,main]: {}
> java.lang.StackOverflowError: null
> at 
> org.apache.cassandra.db.rows.BTreeRow$Builder.build(BTreeRow.java:653) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserializeRowBody(UnfilteredSerializer.java:436)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.UnfilteredDeserializer$CurrentDeserializer.readNext(UnfilteredDeserializer.java:211)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:266)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:153)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:340)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:369)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:189)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:158)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:428)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:288)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:108) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:128)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> {quote}



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

[jira] [Commented] (CASSANDRA-10750) Minor code improvements

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10750:
--

Can you please dig up in which release this made it in for history sake?

> Minor code improvements
> ---
>
> Key: CASSANDRA-10750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10750
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
>
> Went though several IDE inspections and found some places in the code that 
> could be improved. These are just minor improvements and no bug fixes (except 
> one minor "theoretical" thing).
> The [branch on github against 
> trunk|https://github.com/snazy/cassandra/tree/10750-code-opts-trunk] contains 
> a series of commits:
> * simplify Mutation.apply to remove the casts
> * "minor code improvements" just replaces some expressions that are 
> effectively constant
> * remove unused assignments (probably just cosmetic)
> * collapse identical if-branches (probably just cosmetic)
> * empty array constants
> * fix printf usage (could potentially raise an exception in printf)
> * replace tail-recursion in some critical sections (as the JVM cannot 
> optimize that AFAIK)
> * remove methods identical to their super methods (probably just cosmetic)
> [cassci results 
> here|http://cassci.datastax.com/view/Dev/view/snazy/search/?q=snazy-10750-]



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

[jira] [Commented] (CASSANDRA-11258) Repair scheduling - Resource locking API

[Marcus Olsson (JIRA)]

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

Marcus Olsson commented on CASSANDRA-11258:
---

bq. WDYT of this approach?
I like it, it would reduce the amount of work for the write operations while 
keeping a simple structure of the lock keyspace. However, *if* we want to 
visualize all data center locks to the user, it would be more complex to do so.

bq. If you like this approach, we could do the initial version assuming a 
single DC with SimpleStrategy replication + SERIAL consistency, while power 
users could still have multi-DC support by manually changing replication 
settings of the lock keyspace. We could later add transparent/efficient 
multi-DC support via CASSANDRA-11300 and LocalDataCenterReplicationStrategy.
+1

Should we start with {{SimpleStrategy}} and a replication of 3 then? If we only 
have one node there would be no need for repairs and if we have two it would be 
possible to do CAS requests. If we include the 
{{LocalDataCenterReplicationStrategy}} class directly in the first version but 
use SimpleStrategy until CASSANDRA-11300 is in place it should be possible to 
switch to LDCRS automatically later on, assuming that repairs would be paused 
during that upgrade. If we don't include LDCRS directly I think the switch 
would either have to be manual or done by first verifying the version of the 
other nodes, so that the "older" nodes wouldn't complain about an unknown 
replication class.

> Repair scheduling - Resource locking API
> 
>
> Key: CASSANDRA-11258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11258
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Minor
>
> Create a resource locking API & implementation that is able to lock a 
> resource in a specified data center. It should handle priorities to avoid 
> node starvation.



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

[jira] [Commented] (CASSANDRA-11304) Stack overflow when querying 2ndary index

[Job Tiel Groenestege (JIRA)]

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

Job Tiel Groenestege commented on CASSANDRA-11304:
--

Modified some column-names - manually - for readability so I could accidentally 
have created duplicate row names; the original names are a bit longer (but I 
assume that is not the issue here)

{quote}
CREATE TABLE keyspace.tablename (
t ascii,
time timestamp,
aid ascii,
adid int,
ap int,
adc ascii,
aiseid ascii,
aisip boolean,
bpacn int,
bppcn int,
bpusn int,
bcacn int,
bcpcn int,
bcun int,
bid int,
btom int,
cid int,
c ascii,
cacacn int,
cacpcn int,
cacun int,
cac2acn int,
cac2pcn int,
cacun int,
cac3acn int,
cac3pcn int,
cac3un int,
cac4acn int,
cac4pcn int,
cac4un int,
cac5acn int,
cac5pcn int,
cac5un int,
crid int,
dcacn int,
dcpcn int,
dcun int,
dt int,
dc ascii,
du ascii,
est ascii,
et bigint,
evt ascii,
ex ascii,
fp uuid,
flid int,
grid int,
ioid int,
ip ascii,
isp_id int,
l ascii,
liid int,
mtk text,
mts ascii,
mmid int,
mmid int,
ns int,
osid int,
pracn int,
prpcn int,
prusn int,
pmac1acn int,
pmac1pcn int,
pmac1un int,
pmac2acn int,
pmac2pcn int,
pmac2un int,
pmac3acn int,
pmac3pcn int,
pmac3un int,
pmac4acn int,
pmac4pcn int,
pmac5un int,
pmac5acn int,
pmac5pcn int,
pmac6un int,
pc ascii,
rt bigint,
tmcacn int,
tmcpcn int,
tmcun int,
usid int,
url text,
vt bigint,
wpacn int,
wppcn int,
wpusn int,
PRIMARY KEY (uid, time, aid, adid)
) WITH CLUSTERING ORDER BY (time ASC, aid ASC, adid ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
CREATE INDEX fileindex ON keyspace.tablename (fp);
{quote}

> Stack overflow when querying 2ndary index
> -
>
> Key: CASSANDRA-11304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11304
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: 3 Node cluster / Ubuntu 14.04 / Cassandra 3.0.3
>Reporter: Job Tiel Groenestege
>Assignee: Sam Tunnicliffe
>
> When reading data through a secondary index _select * from tableName where 
> secIndexField = 'foo'_  (from a Java application) I get the following 
> stacktrace on all nodes; after the query read fails. It happens repeatably 
> when  I rerun the same query:
> {quote}
> WARN  [SharedPool-Worker-8] 2016-03-04 13:26:28,041 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-8,5,main]: {}
> java.lang.StackOverflowError: null
> at 
> org.apache.cassandra.db.rows.BTreeRow$Builder.build(BTreeRow.java:653) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserializeRowBody(UnfilteredSerializer.java:436)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.UnfilteredDeserializer$CurrentDeserializer.readNext(UnfilteredDeserializer.java:211)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:266)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:153)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:340)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:369)
>  

[jira] [Assigned] (CASSANDRA-11210) Unresolved hostname in replace address

[Jan Karlsson (JIRA)]

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

Jan Karlsson reassigned CASSANDRA-11210:


Assignee: Jan Karlsson

> Unresolved hostname in replace address
> --
>
> Key: CASSANDRA-11210
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11210
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jan Karlsson
>Priority: Minor
>  Labels: lhf
>
> If you provide a hostname which could not be resolved by DNS, it leads to 
> replace args being ignored. If you provide an IP which is not in the cluster, 
> it does the right thing and complain.



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

[jira] [Commented] (CASSANDRA-10992) Hanging streaming sessions

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10992:
-

What is the reaper timeout? Could you try increasing these significantly and 
check if the repair/streams will still hang?

I suspect original repairs are just slow but are being aborted by reaper, and 
currently streams are not stopped when repair is aborted, so when the new 
repair is submitted for the same range new stream sessions will make the 
previous stream sessions hang for some reasons (resource locking or whatever). 
Proper repair cleanup on abort will be implemented on CASSANDRA-11190 and 
should fix those if that's the case.

> Hanging streaming sessions
> --
>
> Key: CASSANDRA-10992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10992
> Project: Cassandra
>  Issue Type: Bug
> Environment: C* 2.1.12, Debian Wheezy
>Reporter: mlowicki
>Assignee: Paulo Motta
> Fix For: 2.1.12
>
> Attachments: apache-cassandra-2.1.12-SNAPSHOT.jar
>
>
> I've started recently running repair using [Cassandra 
> Reaper|https://github.com/spotify/cassandra-reaper]  (built-in {{nodetool 
> repair}} doesn't work for me - CASSANDRA-9935). It behaves fine but I've 
> noticed hanging streaming sessions:
> {code}
> root@db1:~# date
> Sat Jan  9 16:43:00 UTC 2016
> root@db1:~# nt netstats -H | grep total
> Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB 
> total
> Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total
> Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB 
> total
> Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total
> Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB 
> total
> Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total
> Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 
> MB total
> Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total
> Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB 
> total
> Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB 
> total
> root@db1:~# date
> Sat Jan  9 17:45:42 UTC 2016
> root@db1:~# nt netstats -H | grep total
> Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB 
> total
> Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total
> Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB 
> total
> Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total
> Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB 
> total
> Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total
> Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 
> MB total
> Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total
> Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB 
> total
> Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB 
> total
> {code}
> Such sessions are left even when repair job is long time done (confirmed by 
> checking Reaper's and Cassandra's logs). {{streaming_socket_timeout_in_ms}} 
> in cassandra.yaml is set to default value (360).



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

[jira] [Created] (CASSANDRA-11305) Customization of the auto granting process

[Alexandre Linte (JIRA)]

Alexandre Linte created CASSANDRA-11305:
---

 Summary: Customization of the auto granting process
 Key: CASSANDRA-11305
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11305
 Project: Cassandra
  Issue Type: New Feature
  Components: CQL
 Environment: Apache Cassandra 3.3, cqlsh 5.0.1, CQL spec 3.4.0
Reporter: Alexandre Linte
Priority: Minor
 Fix For: 3.3


Hello,

By default, Cassandra implements an auto granting process which is applied when 
a USER | ROLE does a CREATE KEYSPACE, CREATE TABLE, CREATE FUNCTION, CREATE 
AGGREGATE or CREATE ROLE statement. The creator is automatically granted all 
applicable permissions on the new resource.

For example, the ROLE "toto_user" is created and has CREATE permission on its 
personal KEYSPACE "toto_keyspace". Today when toto_user create a TABLE, he is 
automatically granted the following rights:
* ALTER
* DROP
* SELECT
* MODIFY
* AUTHORIZE

Moreover if you want to REVOKE a permission for "toto_user" on a table, this 
table must exist.

The idea of the issue is to improve the auto granting process. I thought about 
a modification of the REVOKE and GRANT SQL commands. You can find below the 
syntax part:
{noformat}
 ::= GRANT ( ALL ( PERMISSIONS )? |  ( 
PERMISSION )? ) ON  TO 

 ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE | DESRIBE 
| EXECUTE

 ::= ALL KEYSPACES
  | KEYSPACE 
  | ( TABLE )? 
  | ALL ROLES
  | ROLE 
  | ALL FUNCTIONS ( IN KEYSPACE  )?
  | FUNCTION 

 ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
{noformat}
{noformat}
 ::= REVOKE ( ALL ( PERMISSIONS )? |  ( 
PERMISSION )? ) ON  FROM 

 ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE | DESRIBE 
| EXECUTE

 ::= ALL KEYSPACES
  | KEYSPACE 
  | ( TABLE )? 
  | ALL ROLES
  | ROLE 
  | ALL FUNCTIONS ( IN KEYSPACE  )?
  | FUNCTION 

 ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
{noformat}
And now multiple the samples part:
{noformat}
GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user;
=> default functioning, when toto_user creates a table he will be automatically 
granted all permissions.

GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE TABLE;
=> grant all permissions to the resource (table) created by toto_user on the 
keyspace toto_keyspace.

GRANT SELECT ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE TABLE;
=> grant select permission to the resource (table) created by toto_user on the 
keyspace toto_keyspace.

REVOKE ALL PERMISSIONS ON KEYSPACE toto_keyspace FROM toto_user;
=> default functioning, toto_user will not be able to do something on the 
keyspace toto_keyspace.

REVOKE AUTHORIZE PERMISSION ON KEYSPACE toto_keyspace FROM toto_user WHEN 
CREATE TABLE;
=> revoke authorize permission to the resource (table) created by toto_user on 
the keyspace toto_keyspace.

REVOKE DROP PERMISSION ALL KEYSPACES FROM toto_user WHEN CREATE ROLE;
=> revoke drop permission to the resource (role) created by toto_user on the 
keyspace toto_keyspace.
{noformat}



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

[jira] [Commented] (CASSANDRA-11304) Stack overflow when querying 2ndary index

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-11304:
-

Can you share the schema of indexed table?

> Stack overflow when querying 2ndary index
> -
>
> Key: CASSANDRA-11304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11304
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: 3 Node cluster / Ubuntu 14.04 / Cassandra 3.0.3
>Reporter: Job Tiel Groenestege
>Assignee: Sam Tunnicliffe
>
> When reading data through a secondary index _select * from tableName where 
> secIndexField = 'foo'_  (from a Java application) I get the following 
> stacktrace on all nodes; after the query read fails. It happens repeatably 
> when  I rerun the same query:
> {quote}
> WARN  [SharedPool-Worker-8] 2016-03-04 13:26:28,041 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-8,5,main]: {}
> java.lang.StackOverflowError: null
> at 
> org.apache.cassandra.db.rows.BTreeRow$Builder.build(BTreeRow.java:653) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserializeRowBody(UnfilteredSerializer.java:436)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.UnfilteredDeserializer$CurrentDeserializer.readNext(UnfilteredDeserializer.java:211)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:266)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:153)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:340)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:369)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:189)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:158)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:428)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:288)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:108) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:128)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> {quote}



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

[jira] [Updated] (CASSANDRA-11304) Stack overflow when querying 2ndary index

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-11304:
-
Summary: Stack overflow when querying 2ndary index  (was: Query data 
through a secondary index)

> Stack overflow when querying 2ndary index
> -
>
> Key: CASSANDRA-11304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11304
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: 3 Node cluster / Ubuntu 14.04 / Cassandra 3.0.3
>Reporter: Job Tiel Groenestege
>
> When reading data through a secondary index _select * from tableName where 
> secIndexField = 'foo'_  (from a Java application) I get the following 
> stacktrace on all nodes; after the query read fails. It happens repeatably 
> when  I rerun the same query:
> {quote}
> WARN  [SharedPool-Worker-8] 2016-03-04 13:26:28,041 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-8,5,main]: {}
> java.lang.StackOverflowError: null
> at 
> org.apache.cassandra.db.rows.BTreeRow$Builder.build(BTreeRow.java:653) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserializeRowBody(UnfilteredSerializer.java:436)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.UnfilteredDeserializer$CurrentDeserializer.readNext(UnfilteredDeserializer.java:211)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:266)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:153)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:340)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:369)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:189)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:158)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:428)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:288)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:108) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:128)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> {quote}



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

[jira] [Updated] (CASSANDRA-11304) Stack overflow when querying 2ndary index

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-11304:
-
Assignee: Sam Tunnicliffe

> Stack overflow when querying 2ndary index
> -
>
> Key: CASSANDRA-11304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11304
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: 3 Node cluster / Ubuntu 14.04 / Cassandra 3.0.3
>Reporter: Job Tiel Groenestege
>Assignee: Sam Tunnicliffe
>
> When reading data through a secondary index _select * from tableName where 
> secIndexField = 'foo'_  (from a Java application) I get the following 
> stacktrace on all nodes; after the query read fails. It happens repeatably 
> when  I rerun the same query:
> {quote}
> WARN  [SharedPool-Worker-8] 2016-03-04 13:26:28,041 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-8,5,main]: {}
> java.lang.StackOverflowError: null
> at 
> org.apache.cassandra.db.rows.BTreeRow$Builder.build(BTreeRow.java:653) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserializeRowBody(UnfilteredSerializer.java:436)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.UnfilteredDeserializer$CurrentDeserializer.readNext(UnfilteredDeserializer.java:211)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:266)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:153)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:340)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:369)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:189)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:158)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:428)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:288)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:108) 
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:128)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133)
>  ~[apache-cassandra-3.0.3.jar:3.0.3]
> {quote}



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

[jira] [Commented] (CASSANDRA-10992) Hanging streaming sessions

[mlowicki (JIRA)]

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

mlowicki commented on CASSANDRA-10992:
--

Repair finished successfully using Cassandra Reaper. It happened during the 
whole process (took couple of days) that Reaper terminated some sessions due to 
timeout (saw that in logs which live watching).

> Hanging streaming sessions
> --
>
> Key: CASSANDRA-10992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10992
> Project: Cassandra
>  Issue Type: Bug
> Environment: C* 2.1.12, Debian Wheezy
>Reporter: mlowicki
>Assignee: Paulo Motta
> Fix For: 2.1.12
>
> Attachments: apache-cassandra-2.1.12-SNAPSHOT.jar
>
>
> I've started recently running repair using [Cassandra 
> Reaper|https://github.com/spotify/cassandra-reaper]  (built-in {{nodetool 
> repair}} doesn't work for me - CASSANDRA-9935). It behaves fine but I've 
> noticed hanging streaming sessions:
> {code}
> root@db1:~# date
> Sat Jan  9 16:43:00 UTC 2016
> root@db1:~# nt netstats -H | grep total
> Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB 
> total
> Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total
> Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB 
> total
> Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total
> Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB 
> total
> Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total
> Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 
> MB total
> Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total
> Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB 
> total
> Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB 
> total
> root@db1:~# date
> Sat Jan  9 17:45:42 UTC 2016
> root@db1:~# nt netstats -H | grep total
> Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB 
> total
> Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total
> Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB 
> total
> Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total
> Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB 
> total
> Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total
> Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 
> MB total
> Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total
> Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB 
> total
> Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB 
> total
> {code}
> Such sessions are left even when repair job is long time done (confirmed by 
> checking Reaper's and Cassandra's logs). {{streaming_socket_timeout_in_ms}} 
> in cassandra.yaml is set to default value (360).



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

[jira] [Commented] (CASSANDRA-10707) Add support for Group By to Select statement

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-10707:


||patch||utests||dtests||
|[trunk|https://github.com/apache/cassandra/compare/trunk...blerer:10707-trunk]|[trunk|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10707-trunk-testall/]|[trunk|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10707-trunk-dtest/]|

I have pushed new commits to handle the last review comments. 

The patch does not fix yet the problem of shortRead but the current 
implementation is definitely broken. As {{countedInCurrentPartition()}} is not 
overridden the row count is used to compute the number of rows to fetch but the 
limit is then set in term of groups.

I have to take something to properly investigate this problem.

{quote}In the news file, you have IN restrictions with only one element are now 
considered as equality restrictions. What does that mean for the user?{quote}

Some queries which use to be rejected will suddenly get accepted like 
multipartitions-queries with {{ORDER BY}} and paging.
Some error messages will also be slightly different. 

I removed the entry for now as I agree that it might not be fully relevant for 
the users.



> Add support for Group By to Select statement
> 
>
> Key: CASSANDRA-10707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10707
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> Now that Cassandra support aggregate functions, it makes sense to support 
> {{GROUP BY}} on the {{SELECT}} statements.
> It should be possible to group either at the partition level or at the 
> clustering column level.
> {code}
> SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey;
> SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP 
> BY partitionKey, clustering0, clustering1; 
> {code}



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

[jira] [Commented] (CASSANDRA-10091) Align JMX authentication with internal authentication

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-10091:
-

[~Jan Karlsson] thanks! I've made those changes, plus a couple of other minor 
tweaks & pushed to my branch. I've also extended your dtest a bit 
[here|https://github.com/beobal/cassandra-dtest/commits/10091]. 

> Align JMX authentication with internal authentication
> -
>
> Key: CASSANDRA-10091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10091
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jan Karlsson
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.x
>
>
> It would be useful to authenticate with JMX through Cassandra's internal 
> authentication. This would reduce the overhead of keeping passwords in files 
> on the machine and would consolidate passwords to one location. It would also 
> allow the possibility to handle JMX permissions in Cassandra.
> It could be done by creating our own JMX server and setting custom classes 
> for the authenticator and authorizer. We could then add some parameters where 
> the user could specify what authenticator and authorizer to use in case they 
> want to make their own.
> This could also be done by creating a premain method which creates a jmx 
> server. This would give us the feature without changing the Cassandra code 
> itself. However I believe this would be a good feature to have in Cassandra.
> I am currently working on a solution which creates a JMX server and uses a 
> custom authenticator and authorizer. It is currently build as a premain, 
> however it would be great if we could put this in Cassandra instead.



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

[jira] [Commented] (CASSANDRA-10992) Hanging streaming sessions

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10992:
-

You're saying the repair finishes successfully, and streaming sessions are 
still reported as being active, or do the repairs also hang? If that's the case 
I suspect reaper's might restarting/killing repairs due to timeout, and they're 
not cleared properly.

Can you check if you see any errors/logs in the log again, and also the 
reaper's log for any retries? In particular, check for any "Terminate session 
is called", to check if {{StorageService.forceTerminateAllRepairSessions}} is 
being called by any chance.

> Hanging streaming sessions
> --
>
> Key: CASSANDRA-10992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10992
> Project: Cassandra
>  Issue Type: Bug
> Environment: C* 2.1.12, Debian Wheezy
>Reporter: mlowicki
>Assignee: Paulo Motta
> Fix For: 2.1.12
>
> Attachments: apache-cassandra-2.1.12-SNAPSHOT.jar
>
>
> I've started recently running repair using [Cassandra 
> Reaper|https://github.com/spotify/cassandra-reaper]  (built-in {{nodetool 
> repair}} doesn't work for me - CASSANDRA-9935). It behaves fine but I've 
> noticed hanging streaming sessions:
> {code}
> root@db1:~# date
> Sat Jan  9 16:43:00 UTC 2016
> root@db1:~# nt netstats -H | grep total
> Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB 
> total
> Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total
> Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB 
> total
> Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total
> Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB 
> total
> Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total
> Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 
> MB total
> Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total
> Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB 
> total
> Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB 
> total
> root@db1:~# date
> Sat Jan  9 17:45:42 UTC 2016
> root@db1:~# nt netstats -H | grep total
> Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB 
> total
> Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total
> Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB 
> total
> Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total
> Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB 
> total
> Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total
> Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 
> MB total
> Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total
> Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB 
> total
> Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB 
> total
> {code}
> Such sessions are left even when repair job is long time done (confirmed by 
> checking Reaper's and Cassandra's logs). {{streaming_socket_timeout_in_ms}} 
> in cassandra.yaml is set to default value (360).



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

[jira] [Commented] (CASSANDRA-11059) In cqlsh show static columns in a different color

[Pavel Trukhanov (JIRA)]

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

Pavel Trukhanov commented on CASSANDRA-11059:
-

That's against the trunk. Please see here 
https://github.com/apache/cassandra/compare/trunk...okmeter:CASSANDRA-11059

But if it works for some previous versions too (need to check that) it still 
won't be backported — it's the policy, right? Or what?

> In cqlsh show static columns in a different color
> -
>
> Key: CASSANDRA-11059
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11059
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
> Environment: [cqlsh 5.0.1 | Cassandra 2.2.3 | CQL spec 3.3.1 | Native 
> protocol v4]
>Reporter: Cédric Hernalsteens
>Priority: Minor
> Fix For: 3.x
>
>
> The partition key columns are shown in red, the clustering columns in cyan, 
> it would be great to also distinguish between the static columns and the 
> other.



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

[jira] [Commented] (CASSANDRA-10992) Hanging streaming sessions

[mlowicki (JIRA)]

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

mlowicki commented on CASSANDRA-10992:
--

The same case after upgrade. Hanging streaming sessions visible in OpsCenter 
and returned by `nodetool netstats`. I've been waiting 2 hours after repair 
finished.

> Hanging streaming sessions
> --
>
> Key: CASSANDRA-10992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10992
> Project: Cassandra
>  Issue Type: Bug
> Environment: C* 2.1.12, Debian Wheezy
>Reporter: mlowicki
>Assignee: Paulo Motta
> Fix For: 2.1.12
>
> Attachments: apache-cassandra-2.1.12-SNAPSHOT.jar
>
>
> I've started recently running repair using [Cassandra 
> Reaper|https://github.com/spotify/cassandra-reaper]  (built-in {{nodetool 
> repair}} doesn't work for me - CASSANDRA-9935). It behaves fine but I've 
> noticed hanging streaming sessions:
> {code}
> root@db1:~# date
> Sat Jan  9 16:43:00 UTC 2016
> root@db1:~# nt netstats -H | grep total
> Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB 
> total
> Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total
> Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB 
> total
> Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total
> Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB 
> total
> Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total
> Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 
> MB total
> Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total
> Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB 
> total
> Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB 
> total
> root@db1:~# date
> Sat Jan  9 17:45:42 UTC 2016
> root@db1:~# nt netstats -H | grep total
> Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB 
> total
> Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total
> Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB 
> total
> Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total
> Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB 
> total
> Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total
> Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66 
> MB total
> Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total
> Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB 
> total
> Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB 
> total
> {code}
> Such sessions are left even when repair job is long time done (confirmed by 
> checking Reaper's and Cassandra's logs). {{streaming_socket_timeout_in_ms}} 
> in cassandra.yaml is set to default value (360).



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

[jira] [Created] (CASSANDRA-11304) Query data through a secondary index

[Job Tiel Groenestege (JIRA)]

Job Tiel Groenestege created CASSANDRA-11304:


 Summary: Query data through a secondary index
 Key: CASSANDRA-11304
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11304
 Project: Cassandra
  Issue Type: Bug
  Components: Core, CQL
 Environment: 3 Node cluster / Ubuntu 14.04 / Cassandra 3.0.3
Reporter: Job Tiel Groenestege


When reading data through a secondary index _select * from tableName where 
secIndexField = 'foo'_  (from a Java application) I get the following 
stacktrace on all nodes; after the query read fails. It happens repeatably when 
 I rerun the same query:

{quote}
WARN  [SharedPool-Worker-8] 2016-03-04 13:26:28,041 
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
Thread[SharedPool-Worker-8,5,main]: {}
java.lang.StackOverflowError: null
at 
org.apache.cassandra.db.rows.BTreeRow$Builder.build(BTreeRow.java:653) 
~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.db.rows.UnfilteredSerializer.deserializeRowBody(UnfilteredSerializer.java:436)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.db.UnfilteredDeserializer$CurrentDeserializer.readNext(UnfilteredDeserializer.java:211)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:266)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:153)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:340)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:369)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:189)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:158)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:428)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:288)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:108) 
~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:128)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
at 
org.apache.cassandra.index.internal.composites.CompositesSearcher$1.prepareNext(CompositesSearcher.java:133)
 ~[apache-cassandra-3.0.3.jar:3.0.3]
{quote}



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

[jira] [Commented] (CASSANDRA-10707) Add support for Group By to Select statement

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-10707:


I missed the problem of the counted. Yes, I agree with your statement the short 
read logic will probably not work for group by.
I will look deeper in it.

> Add support for Group By to Select statement
> 
>
> Key: CASSANDRA-10707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10707
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> Now that Cassandra support aggregate functions, it makes sense to support 
> {{GROUP BY}} on the {{SELECT}} statements.
> It should be possible to group either at the partition level or at the 
> clustering column level.
> {code}
> SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey;
> SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP 
> BY partitionKey, clustering0, clustering1; 
> {code}



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

[jira] [Commented] (CASSANDRA-10707) Add support for Group By to Select statement

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-10707:


{quote}I noticed that CQLLimits.forShortReadRetry() does not provide any limit 
on the number of rows either.{quote}
It looks like I was really tired when I looked at the code :-(

{quote}Not sure about CQLGroupByLimits.forShortReadRetry(). I believe putting 
no limit on the number of rows (and only on the group) might lead to OOM. In 
fact, I need to think more carefully about this but I'm not 100% sure that the 
short read logic isn't throw off by the fact that counted() returns a number of 
groups not rows.{quote}

I think my implementation for {{forShortReadRetry()}} is simply wrong. The goal 
of the short read retry is to fetch the rows that were missing for a given 
partition due to short read. As the number of rows to request is computed in 
{{ShortReadRowProtection:: moreContents}} I believe that even in the case of 
{{GROUP BY}} we should use a {{CQLLimits}} to request the rows.



> Add support for Group By to Select statement
> 
>
> Key: CASSANDRA-10707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10707
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> Now that Cassandra support aggregate functions, it makes sense to support 
> {{GROUP BY}} on the {{SELECT}} statements.
> It should be possible to group either at the partition level or at the 
> clustering column level.
> {code}
> SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey;
> SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP 
> BY partitionKey, clustering0, clustering1; 
> {code}



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

[jira] [Commented] (CASSANDRA-6377) ALLOW FILTERING should allow seq scan filtering

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-6377:


+1 on the patches, +0 on changing the ticket type. 

A quick grep shows there are quite a few places in tests (on all 3 branches) 
where we should use {{StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE}}, 
I know it's very nit-picky, but it would be good to fix those on commit.


> ALLOW FILTERING should allow seq scan filtering
> ---
>
> Key: CASSANDRA-6377
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6377
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Benjamin Lerer
>  Labels: cql
> Fix For: 3.0.x, 3.x
>
>
> CREATE TABLE emp_table2 (
> empID int PRIMARY KEY,
> firstname text,
> lastname text,
> b_mon text,
> b_day text,
> b_yr text,
> );
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (100,'jane','doe','oct','31','1980');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (101,'john','smith','jan','01','1981');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (102,'mary','jones','apr','15','1982');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
>VALUES (103,'tim','best','oct','25','1982');
>
> SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2 
> WHERE b_mon='oct' ALLOW FILTERING;
> Bad Request: No indexed columns present in by-columns clause with Equal 
> operator



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

[jira] [Commented] (CASSANDRA-11299) AssertionError when quering by secondary index

[JIRA]

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

Michał Matłoka commented on CASSANDRA-11299:


And I had at a same time case where 
{code}
select * from table where id = 'sth';
{code}
returned 2 rows, with different subsets of columns (like second row would be 
comming from a specific update query)

This was ultra strange, especially because any repair didn't handle that.

> AssertionError when quering by secondary index
> --
>
> Key: CASSANDRA-11299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11299
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.3
>Reporter: Michał Matłoka
>
> Hi,
> Recently we have upgraded from Cassandra 2.2.4 to 3.3. I have issues with one 
> table. When I try to query using any secondary index I get e.g. in cqlsh
> {code}
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1249, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py",
>  line 3122, in result
> raise self._final_exception
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation 
> failed - received 0 responses and 1 failures" info={'failures': 1, 
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}
> Node logs shows then:
> {code}
> [[AWARN  [SharedPool-Worker-2] 2016-03-03 00:47:01,679 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-2,5,main]: {}
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:225)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:215)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116) 
> ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:133)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:89)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:294)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:134)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:127)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) 
> ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:292) 
> ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1789)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2457)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_66]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.3.0.jar:3.3.0]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.3.0.jar:3.3.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66]
> {code}
> SStables are upgraded, I have tried repair and scrub. I have tried to rebuild 
> indexes, and even remove them and re-add them.It occurs on every cluster node.
> Additionally I had seen in this table case where PRIMARY KEY was 
> duplicated!!! (there were two rows with same primary key, by seeing what 
> columns were set I can say one was 

[jira] [Commented] (CASSANDRA-11299) AssertionError when quering by secondary index

[JIRA]

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

Michał Matłoka commented on CASSANDRA-11299:


{code}
CREATE TABLE mykeyspace.mytable (
id text PRIMARY KEY,
attributes map,
someflag boolean,
sometimestamp1 timestamp,
sometimestamp2 timestamp,
sometimestamp3 timestamp,
sometimestamp4 timestamp,
sometimestamp5 timestamp,
someotherflag boolean,
systemotherattributes map
) WITH bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
CREATE INDEX mytable_sometimestamp1_idx ON mykeyspace.mytable (sometimestamp1);
CREATE INDEX mytable_someflag_idx ON mykeyspace.mytable (someflag);
CREATE INDEX mytable_systemotherattributes_idx ON mykeyspace.mytable 
(keys(systemotherattributes));
{code}
so using those column names the problematic queries were e.g.:
{code}
select * from table where someflag = true;
{code}
{code}
select * from table where systemotherattributes contains key 'Sth';
{code}
{code}
select * from table where someflag = true and sometimestamp1 > '2016';
{code}

> AssertionError when quering by secondary index
> --
>
> Key: CASSANDRA-11299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11299
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.3
>Reporter: Michał Matłoka
>
> Hi,
> Recently we have upgraded from Cassandra 2.2.4 to 3.3. I have issues with one 
> table. When I try to query using any secondary index I get e.g. in cqlsh
> {code}
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1249, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py",
>  line 3122, in result
> raise self._final_exception
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation 
> failed - received 0 responses and 1 failures" info={'failures': 1, 
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}
> Node logs shows then:
> {code}
> [[AWARN  [SharedPool-Worker-2] 2016-03-03 00:47:01,679 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-2,5,main]: {}
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:225)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:215)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116) 
> ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:133)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:89)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:294)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:134)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:127)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) 
> ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:292) 
> ~[apache-cassandra-3.3.0.jar:3.3.0]
>