[jira] [Commented] (CASSANDRA-13530) GroupCommitLogService

2017-05-16 Thread Yuji Ito (JIRA) 

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

Yuji Ito commented on CASSANDRA-13530:
--

I tried the measurement with `concurrent_reads: 512` and `concurrent_writes: 
512`.

I'll try Guava rate limiter to generate requests.

> GroupCommitLogService
> -
>
> Key: CASSANDRA-13530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13530
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Yuji Ito
>Assignee: Yuji Ito
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
> Attachments: groupCommit22.patch, groupCommit30.patch, 
> groupCommit3x.patch, MicroRequestThread.java
>
>
> I propose a new CommitLogService, GroupCommitLogService, to improve the 
> throughput when lots of requests are received.
> It improved the throughput by maximum 94%.
> I'd like to discuss about this CommitLogService.
> Currently, we can select either 2 CommitLog services; Periodic and Batch.
> In Periodic, we might lose some commit log which hasn't written to the disk.
> In Batch, we can write commit log to the disk every time. The size of commit 
> log to write is too small (< 4KB). When high concurrency, these writes are 
> gathered and persisted to the disk at once. But, when insufficient 
> concurrency, many small writes are issued and the performance decreases due 
> to the latency of the disk. Even if you use SSD, processes of many IO 
> commands decrease the performance.
> GroupCommitLogService writes some commitlog to the disk at once.
> The patch adds GroupCommitLogService (It is enabled by setting 
> `commitlog_sync` and `commitlog_sync_group_window_in_ms` in cassandra.yaml).
> The difference from Batch is just only waiting for the semaphore.
> By waiting for the semaphore, some writes for commit logs are executed at the 
> same time.
> In GroupCommitLogService, the latency becomes worse if the there is no 
> concurrency.
> I measured the performance with my microbench (MicroRequestThread.java) by 
> increasing the number of threads.The cluster has 3 nodes (Replication factor: 
> 3). Each nodes is AWS EC2 m4.large instance + 200IOPS io1 volume.
> The result is as below. The GroupCommitLogService with 10ms window improved 
> update with Paxos by 94% and improved select with Paxos by 76%.
> h6. SELECT / sec
> ||\# of threads||Batch 2ms||Group 10ms||
> |1|192|103|
> |2|163|212|
> |4|264|416|
> |8|454|800|
> |16|744|1311|
> |32|1151|1481|
> |64|1767|1844|
> |128|2949|3011|
> |256|4723|5000|
> h6. UPDATE / sec
> ||\# of threads||Batch 2ms||Group 10ms||
> |1|45|26|
> |2|39|51|
> |4|58|102|
> |8|102|198|
> |16|167|213|
> |32|289|295|
> |64|544|548|
> |128|1046|1058|
> |256|2020|2061|



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13182) test failure in sstableutil_test.SSTableUtilTest.compaction_test

2017-05-16 Thread Lerh Chuan Low (JIRA) 

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

Lerh Chuan Low edited comment on CASSANDRA-13182 at 5/17/17 1:19 AM:
-

The PR has been merged here: 
https://github.com/riptano/cassandra-dtest/pull/1473

As a side note, [~krummas] it seems that in this commit 
[d26187e5c2ab2cf08d8c874387b4674b860f5e4d|https://github.com/apache/cassandra/commit/d26187e5c2ab2cf08d8c874387b4674b860f5e4d]
 it looks like {{enable}} and {{disable}} have empty method bodies and they 
aren't overriden anywhere. Just wondering if they were intentionally left that 
way and if we should remove them? They confused me to mistakenly thinking 
disabling auto compaction wasn't working. It will be a really simple patch, 
like so (that's based on {{trunk}}, it's in both 3.0.X and 3.X): 
https://github.com/apache/cassandra/compare/trunk...juiceblender:13182-autocompaction

Let me know what you think - also happy to create another JIRA instead and 
close this one :)


was (Author: lerh low):
The PR has been merged here: 
https://github.com/riptano/cassandra-dtest/pull/1473

As a side note, [~krummas] it seems that in this commit 
[d26187e5c2ab2cf08d8c874387b4674b860f5e4d|https://github.com/apache/cassandra/commit/d26187e5c2ab2cf08d8c874387b4674b860f5e4d]
 it looks like {{enable}} and {{disable}} have empty method bodies and they 
aren't overriden anywhere. Just wondering if they were intentionally left that 
way and if we should remove them? They confused me to mistakenly thinking 
disabling auto compaction wasn't working. It will be a really simple patch, 
like so (that's based on {{trunk}}: 
https://github.com/apache/cassandra/compare/trunk...juiceblender:13182-autocompaction

Let me know what you think - also happy to create another JIRA instead and 
close this one :)

> test failure in sstableutil_test.SSTableUtilTest.compaction_test
> 
>
> Key: CASSANDRA-13182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13182
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Shuler
>Assignee: Lerh Chuan Low
>  Labels: dtest, test-failure, test-failure-fresh
> Attachments: node1_debug.log, node1_gc.log, node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/506/testReport/sstableutil_test/SSTableUtilTest/compaction_test
> {noformat}
> Error Message
> Lists differ: ['/tmp/dtest-Rk_3Cs/test/node1... != 
> ['/tmp/dtest-Rk_3Cs/test/node1...
> First differing element 8:
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-CRC.db'
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-6-big-CRC.db'
> First list contains 7 additional elements.
> First extra element 24:
> '/tmp/dtest-Rk_3Cs/test/node1/data2/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-5-big-Data.db'
>   
> ['/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-CRC.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-Data.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-Digest.crc32',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-Filter.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-Index.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-Statistics.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-Summary.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-TOC.txt',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-CRC.db',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-Digest.crc32',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-Filter.db',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-Index.db',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-Statistics.db',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-Summary.db',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-TOC.txt',
>
>

[jira] [Commented] (CASSANDRA-13182) test failure in sstableutil_test.SSTableUtilTest.compaction_test

2017-05-16 Thread Lerh Chuan Low (JIRA) 

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

Lerh Chuan Low commented on CASSANDRA-13182:


The PR has been merged here: 
https://github.com/riptano/cassandra-dtest/pull/1473

As a side note, [~krummas] it seems that in this commit 
[d26187e5c2ab2cf08d8c874387b4674b860f5e4d|https://github.com/apache/cassandra/commit/d26187e5c2ab2cf08d8c874387b4674b860f5e4d]
 it looks like {{enable}} and {{disable}} have empty method bodies and they 
aren't overriden anywhere. Just wondering if they were intentionally left that 
way and if we should remove them? They confused me to mistakenly thinking 
disabling auto compaction wasn't working. It will be a really simple patch, 
like so (that's based on {{trunk}}: 
https://github.com/apache/cassandra/compare/trunk...juiceblender:13182-autocompaction

Let me know what you think - also happy to create another JIRA instead and 
close this one :)

> test failure in sstableutil_test.SSTableUtilTest.compaction_test
> 
>
> Key: CASSANDRA-13182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13182
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Shuler
>Assignee: Lerh Chuan Low
>  Labels: dtest, test-failure, test-failure-fresh
> Attachments: node1_debug.log, node1_gc.log, node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/506/testReport/sstableutil_test/SSTableUtilTest/compaction_test
> {noformat}
> Error Message
> Lists differ: ['/tmp/dtest-Rk_3Cs/test/node1... != 
> ['/tmp/dtest-Rk_3Cs/test/node1...
> First differing element 8:
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-CRC.db'
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-6-big-CRC.db'
> First list contains 7 additional elements.
> First extra element 24:
> '/tmp/dtest-Rk_3Cs/test/node1/data2/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-5-big-Data.db'
>   
> ['/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-CRC.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-Data.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-Digest.crc32',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-Filter.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-Index.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-Statistics.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-Summary.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data0/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-4-big-TOC.txt',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-CRC.db',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-Digest.crc32',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-Filter.db',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-Index.db',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-Statistics.db',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-Summary.db',
> -  
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-2-big-TOC.txt',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-6-big-CRC.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-6-big-Data.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-6-big-Digest.crc32',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-6-big-Filter.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-6-big-Index.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-6-big-Statistics.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-6-big-Summary.db',
>
> '/tmp/dtest-Rk_3Cs/test/node1/data1/keyspace1/standard1-11ee2450e8ab11e6b5a68de39eb517c4/mc-6-big-TOC.txt',
>
>

[jira] [Commented] (CASSANDRA-12888) Incremental repairs broken for MVs and CDC

2017-05-16 Thread Blake Eggleston (JIRA) 

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

Blake Eggleston commented on CASSANDRA-12888:
-

+1 on the design doc, or at least a comment thoroughly explaining the approach, 
since this seems to be a bit different from what was discussed above. Paulo, 
you're correct about #9143, we're going to need to preserve the pendingRepair 
value as well.

At a high level though, I think the patch, and some of the solutions discussed, 
are approaching the problem from the wrong direction. Having to bend and 
repurpose storage system components like this to make streaming and repair work 
properly, to me, indicates there’s a problem in the MV implementation. 
Specifically, we shouldn't have to rewrite data that was just streamed. I think 
it would be better to focus on fixing those problems, instead of adding 
complexity to the storage layer to work around them. The contents of Mutations 
and UnfilteredRowIterators are pretty similar, decoupling the MV code from the 
write path should make it possible to apply the MV logic to sstable data 
without having to run it through the entire write path.

> Incremental repairs broken for MVs and CDC
> --
>
> Key: CASSANDRA-12888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12888
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Stefan Podkowinski
>Assignee: Benjamin Roth
> Fix For: 3.0.x, 3.11.x
>
>
> SSTables streamed during the repair process will first be written locally and 
> afterwards either simply added to the pool of existing sstables or, in case 
> of existing MVs or active CDC, replayed on mutation basis:
> As described in {{StreamReceiveTask.OnCompletionRunnable}}:
> {quote}
> We have a special path for views and for CDC.
> For views, since the view requires cleaning up any pre-existing state, we 
> must put all partitions through the same write path as normal mutations. This 
> also ensures any 2is are also updated.
> For CDC-enabled tables, we want to ensure that the mutations are run through 
> the CommitLog so they can be archived by the CDC process on discard.
> {quote}
> Using the regular write path turns out to be an issue for incremental 
> repairs, as we loose the {{repaired_at}} state in the process. Eventually the 
> streamed rows will end up in the unrepaired set, in contrast to the rows on 
> the sender site moved to the repaired set. The next repair run will stream 
> the same data back again, causing rows to bounce on and on between nodes on 
> each repair.
> See linked dtest on steps to reproduce. An example for reproducing this 
> manually using ccm can be found 
> [here|https://gist.github.com/spodkowinski/2d8e0408516609c7ae701f2bf1e515e8]



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13533) ColumnIdentifier object size wrong when tables are not flushed

2017-05-16 Thread Eduard Tudenhoefner (JIRA) 

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

Eduard Tudenhoefner commented on CASSANDRA-13533:
-

[~jjirsa] we were using that flag in some of our integration tests where we 
found out that, _very rarely_, simple things (usually taking < 1 second) would 
take a long amount of time (> 30 seconds). 

We boiled it then down to the point where we saw that this time was 99% spent 
in the prepared stmt cache for adding/evicting elements. And in our case, 
eviction was happening because a single prepared stmt would account *1mb - 6mb* 
(prep stmt cache size was *8mb* for us). After looking closer why prep stmts 
would be so large, we eventually saw that the binary representation of 
{{ColumnIdentifier#text}} was be wrong and not what we would have expected (see 
attached screenshot).

We also only detected all of this because on *cassandra-3.0* we don't use 
*.omitSharedBufferOverhead()* with {{MemoryMeter}} object measurements ( 
[QueryProcessor.java#L67|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L67]).
 
On *cassandra-3.11* things got refactored over time and the prep stmt cache was 
using {{MemoryMeter}} stuff from {{ObjectSizes}}, where 
*.omitSharedBufferOverhead()* is being applied and the issue wouldn't happen 
([ObjectSizes.java#L35|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/utils/ObjectSizes.java#L35]).



> ColumnIdentifier object size wrong when tables are not flushed
> --
>
> Key: CASSANDRA-13533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13533
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
> Fix For: 3.0.14, 3.11.0, 4.0
>
> Attachments: columnidentifier.png
>
>
> It turns out that the object size of {{ColumnIdentifier}} is wrong when 
> *cassandra.test.flush_local_schema_changes: false*. This looks like stuff is 
> being wrongly reused when no flush is happening.
> We only noticed this because we were using the prepared stmt cache and 
> noticed that prepared statements would account for *1-6mb* when 
> *cassandra.test.flush_local_schema_changes: false*. With 
> *cassandra.test.flush_local_schema_changes: true* (which is the default) 
> those would be around *5000 bytes*.
> Attached is a test that reproduces the problem and also a fix.
> Also after talking to [~jkni] / [~blerer] we shouldn't probably take 
> {{ColumnDefinition}} into account when measuring object sizes with 
> {{MemoryMeter}}



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13533) ColumnIdentifier object size wrong when tables are not flushed

2017-05-16 Thread Eduard Tudenhoefner (JIRA) 

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

Eduard Tudenhoefner updated CASSANDRA-13533:

Attachment: columnidentifier.png

> ColumnIdentifier object size wrong when tables are not flushed
> --
>
> Key: CASSANDRA-13533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13533
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
> Fix For: 3.0.14, 3.11.0, 4.0
>
> Attachments: columnidentifier.png
>
>
> It turns out that the object size of {{ColumnIdentifier}} is wrong when 
> *cassandra.test.flush_local_schema_changes: false*. This looks like stuff is 
> being wrongly reused when no flush is happening.
> We only noticed this because we were using the prepared stmt cache and 
> noticed that prepared statements would account for *1-6mb* when 
> *cassandra.test.flush_local_schema_changes: false*. With 
> *cassandra.test.flush_local_schema_changes: true* (which is the default) 
> those would be around *5000 bytes*.
> Attached is a test that reproduces the problem and also a fix.
> Also after talking to [~jkni] / [~blerer] we shouldn't probably take 
> {{ColumnDefinition}} into account when measuring object sizes with 
> {{MemoryMeter}}



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13533) ColumnIdentifier object size wrong when tables are not flushed

2017-05-16 Thread Jeff Jirsa (JIRA) 

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

Jeff Jirsa commented on CASSANDRA-13533:


{quote}
This looks like stuff is being wrongly reused when no flush is happening
{quote}

Obviously that flag is only for unit tests, but can you describe the symptom 
that led you to finding/fixing this?  





> ColumnIdentifier object size wrong when tables are not flushed
> --
>
> Key: CASSANDRA-13533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13533
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
> Fix For: 3.0.14, 3.11.0, 4.0
>
>
> It turns out that the object size of {{ColumnIdentifier}} is wrong when 
> *cassandra.test.flush_local_schema_changes: false*. This looks like stuff is 
> being wrongly reused when no flush is happening.
> We only noticed this because we were using the prepared stmt cache and 
> noticed that prepared statements would account for *1-6mb* when 
> *cassandra.test.flush_local_schema_changes: false*. With 
> *cassandra.test.flush_local_schema_changes: true* (which is the default) 
> those would be around *5000 bytes*.
> Attached is a test that reproduces the problem and also a fix.
> Also after talking to [~jkni] / [~blerer] we shouldn't probably take 
> {{ColumnDefinition}} into account when measuring object sizes with 
> {{MemoryMeter}}



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12982) Customizable hint ttl has been removed

2017-05-16 Thread Blake Eggleston (JIRA) 

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

Blake Eggleston updated CASSANDRA-12982:

Fix Version/s: (was: 3.11.x)
   4.0

> Customizable hint ttl has been removed
> --
>
> Key: CASSANDRA-12982
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12982
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 4.0
>
>
> The cassandra.maxHintTTL property added in CASSANDRA-5988 was removed in the 
> hint system rewrite for 3.0.



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12982) Customizable hint ttl has been removed

2017-05-16 Thread Blake Eggleston (JIRA) 

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

Blake Eggleston updated CASSANDRA-12982:

Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

Committed to trunk as {{f8159ac5071d53e8bc9c28e3a1eaf3ba798ff287}}

> Customizable hint ttl has been removed
> --
>
> Key: CASSANDRA-12982
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12982
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 3.11.x
>
>
> The cassandra.maxHintTTL property added in CASSANDRA-5988 was removed in the 
> hint system rewrite for 3.0.



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

cassandra git commit: Bring back maxHintTTL propery

2017-05-16 Thread bdeggleston 
Repository: cassandra
Updated Branches:
  refs/heads/trunk 01ade6f25 -> f8159ac50


Bring back maxHintTTL propery

Patch by Blake Eggleston, reviewed by Aleksey Yeschenko for CASSANDRA-12982


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

Branch: refs/heads/trunk
Commit: f8159ac5071d53e8bc9c28e3a1eaf3ba798ff287
Parents: 01ade6f
Author: Blake Eggleston 
Authored: Tue Nov 8 14:11:47 2016 -0800
Committer: Blake Eggleston 
Committed: Tue May 16 14:37:33 2017 -0700

--
 CHANGES.txt |   1 +
 conf/jvm.options|   3 +
 src/java/org/apache/cassandra/hints/Hint.java   |  82 -
 .../org/apache/cassandra/hints/HintsReader.java |   7 +-
 .../org/apache/cassandra/hints/HintsWriter.java |   6 +
 .../io/util/RebufferingInputStream.java |   2 +-
 .../apache/cassandra/utils/vint/VIntCoding.java |   1 +
 .../cassandra/hints/HintWriteTTLTest.java   | 169 +++
 8 files changed, 263 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f8159ac5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 03870dd..9d1323d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Bring back maxHintTTL propery (CASSANDRA-12982)
  * Add testing guidelines (CASSANDRA-13497)
  * Add more repair metrics (CASSANDRA-13531)
  * RangeStreamer should be smarter when picking endpoints for streaming 
(CASSANDRA-4650)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f8159ac5/conf/jvm.options
--
diff --git a/conf/jvm.options b/conf/jvm.options
index 49b2196..398b52f 100644
--- a/conf/jvm.options
+++ b/conf/jvm.options
@@ -79,6 +79,9 @@
 # 1 rows per page.
 #-Dcassandra.force_default_indexing_page_size=true
 
+# Imposes an upper bound on hint lifetime below the normal min gc_grace_seconds
+#-Dcassandra.maxHintTTL=max_hint_ttl_in_seconds
+
 
 # GENERAL JVM SETTINGS #
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f8159ac5/src/java/org/apache/cassandra/hints/Hint.java
--
diff --git a/src/java/org/apache/cassandra/hints/Hint.java 
b/src/java/org/apache/cassandra/hints/Hint.java
index 1582a3c..b0abd50 100644
--- a/src/java/org/apache/cassandra/hints/Hint.java
+++ b/src/java/org/apache/cassandra/hints/Hint.java
@@ -24,11 +24,17 @@ import java.util.concurrent.TimeUnit;
 
 import com.google.common.base.Throwables;
 
+import javax.annotation.Nullable;
+
+import com.google.common.primitives.Ints;
+
 import org.apache.cassandra.db.*;
 import org.apache.cassandra.io.IVersionedSerializer;
+import org.apache.cassandra.io.util.DataInputBuffer;
 import org.apache.cassandra.io.util.DataInputPlus;
 import org.apache.cassandra.io.util.DataOutputPlus;
 import org.apache.cassandra.schema.TableId;
+import org.apache.cassandra.utils.vint.VIntCoding;
 
 import static org.apache.cassandra.db.TypeSizes.sizeof;
 import static org.apache.cassandra.db.TypeSizes.sizeofUnsignedVInt;
@@ -51,10 +57,11 @@ import static 
org.apache.cassandra.db.TypeSizes.sizeofUnsignedVInt;
 public final class Hint
 {
 public static final Serializer serializer = new Serializer();
+static final int maxHintTTL = Integer.getInteger("cassandra.maxHintTTL", 
Integer.MAX_VALUE);
 
 final Mutation mutation;
 final long creationTime;  // time of hint creation (in milliseconds)
-final int gcgs; // the smallest gc gs of all involved tables
+final int gcgs; // the smallest gc gs of all involved tables (in seconds)
 
 private Hint(Mutation mutation, long creationTime, int gcgs)
 {
@@ -115,13 +122,25 @@ public final class Hint
 }
 
 /**
+ * @return the overall ttl of the hint - the minimum of all mutation's 
tables' gc gs now and at the time of creation
+ */
+int ttl()
+{
+return Math.min(gcgs, mutation.smallestGCGS());
+}
+
+/**
  * @return calculates whether or not it is safe to apply the hint without 
risking to resurrect any deleted data
  */
 boolean isLive()
 {
-int smallestGCGS = Math.min(gcgs, mutation.smallestGCGS());
-long expirationTime = creationTime + 
TimeUnit.SECONDS.toMillis(smallestGCGS);
-return expirationTime > System.currentTimeMillis();
+return isLive(creationTime, System.currentTimeMillis(), ttl());
+}
+
+static boolean isLive(long creationTime,

[jira] [Resolved] (CASSANDRA-13534) Docs: Add Jenkins setup guide

2017-05-16 Thread Stefan Podkowinski (JIRA) 

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

Stefan Podkowinski resolved CASSANDRA-13534.

Resolution: Fixed

Merged as 01ade6f251314a7a438f6398f4fad95a6b5eb8b3

> Docs: Add Jenkins setup guide
> -
>
> Key: CASSANDRA-13534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13534
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 4.0
>
>
> * Add new Jenkins setup guide
> * Replace some references to cassci with builds.apache.org



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

cassandra git commit: Docs: add Jenkins setup details

2017-05-16 Thread spod 
Repository: cassandra
Updated Branches:
  refs/heads/trunk 7583c9b96 -> 01ade6f25


Docs: add Jenkins setup details

patch by Stefan Podkowinski; reviewed by Michael Shuler for CASSANDRA-13534


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

Branch: refs/heads/trunk
Commit: 01ade6f251314a7a438f6398f4fad95a6b5eb8b3
Parents: 7583c9b
Author: Stefan Podkowinski 
Authored: Tue May 16 21:12:08 2017 +0200
Committer: Stefan Podkowinski 
Committed: Tue May 16 23:07:12 2017 +0200

--
 doc/source/development/ci.rst  | 72 +
 doc/source/development/ide.rst |  4 --
 doc/source/development/index.rst   |  1 +
 doc/source/development/patches.rst |  2 +-
 doc/source/development/testing.rst |  2 +-
 5 files changed, 75 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/01ade6f2/doc/source/development/ci.rst
--
diff --git a/doc/source/development/ci.rst b/doc/source/development/ci.rst
new file mode 100644
index 000..192b188
--- /dev/null
+++ b/doc/source/development/ci.rst
@@ -0,0 +1,72 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+.. or more contributor license agreements.  See the NOTICE file
+.. distributed with this work for additional information
+.. regarding copyright ownership.  The ASF licenses this file
+.. to you under the Apache License, Version 2.0 (the
+.. "License"); you may not use this file except in compliance
+.. with the License.  You may obtain a copy of the License at
+..
+.. http://www.apache.org/licenses/LICENSE-2.0
+..
+.. Unless required by applicable law or agreed to in writing, software
+.. distributed under the License is distributed on an "AS IS" BASIS,
+.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+.. See the License for the specific language governing permissions and
+.. limitations under the License.
+
+Jenkins CI Environment
+**
+
+About CI testing and Apache Cassandra
+=
+
+Cassandra can be automatically tested using various test suites, that are 
either implemented based on JUnit or the `dtest 
`_ scripts written in Python. As 
outlined in :doc:`testing`, each kind of test suite addresses a different way 
how to test Cassandra. But in the end, all of them will be executed together on 
our CI platform at `builds.apache.org `_, running 
`Jenkins `_.
+
+
+
+Setting up your own Jenkins server
+==
+
+Jenkins is an open source solution that can be installed on a large number of 
platforms. Setting up a custom Jenkins instance for Cassandra may be desirable 
for users who have hardware to spare, or organizations that want to run 
Cassandra tests for custom patches before contribution.
+
+Please refer to the Jenkins download and documentation pages for details on 
how to get Jenkins running, possibly also including slave build executor 
instances. The rest of the document will focus on how to setup Cassandra jobs 
in your Jenkins environment.
+
+Required plugins
+
+
+The following plugins need to be installed additionally to the standard 
plugins (git, ant, ..).
+
+You can install any missing plugins through the install manager.
+
+Go to ``Manage Jenkins -> Manage Plugins -> Available`` and install the 
following plugins and respective dependencies:
+
+* Job DSL
+* Javadoc Plugin
+* description setter plugin
+* Throttle Concurrent Builds Plug-in
+* Test stability history
+* Hudson Post build task
+
+
+Setup seed job
+--
+
+Config ``New Item``
+
+* Name it ``Cassandra-Job-DSL``
+* Select ``Freestyle project``
+
+Under ``Source Code Management`` select Git using the repository: 
``https://github.com/apache/cassandra-builds``
+
+Under ``Build``, confirm ``Add build step`` -> ``Process Job DSLs`` and enter 
at ``Look on Filesystem``: ``jenkins-dsl/cassandra_job_dsl_seed.groovy``
+
+Generated jobs will be created based on the Groovy script's default settings. 
You may want to override settings by checking ``This project is parameterized`` 
and add ``String Parameter`` for on the variables that can be found in the top 
of the script. This will allow you to setup jobs for your own repository and 
branches (e.g. working branches).
+
+**When done, confirm "Save"**
+
+You should now find a new entry with the given name in your project list. 
However, building the project will still fail and

[jira] [Created] (CASSANDRA-13534) Docs: Add Jenkins setup guide

2017-05-16 Thread Stefan Podkowinski (JIRA) 
Stefan Podkowinski created CASSANDRA-13534:
--

 Summary: Docs: Add Jenkins setup guide
 Key: CASSANDRA-13534
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13534
 Project: Cassandra
  Issue Type: Improvement
  Components: Documentation and Website
Reporter: Stefan Podkowinski
Assignee: Stefan Podkowinski
 Fix For: 4.0


* Add new Jenkins setup guide
* Replace some references to cassci with builds.apache.org



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

cassandra-builds git commit: Unify version handling for docker based package building

2017-05-16 Thread spod 
Repository: cassandra-builds
Updated Branches:
  refs/heads/master 81ab99ead -> f3fdb2bd9


Unify version handling for docker based package building

Build either snapshot or release packages based on specified git path.
Releases will only be build from tags. Provided changes will simplify
manual invocation of docker for developers, as well as making it
possible to automatically build packages in Jenkins at some point.

Closes #3


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

Branch: refs/heads/master
Commit: f3fdb2bd94b0128a90fabec6809d7397fa9df8b5
Parents: 81ab99e
Author: Stefan Podkowinski 
Authored: Tue May 16 20:20:11 2017 +0200
Committer: Stefan Podkowinski 
Committed: Tue May 16 22:57:55 2017 +0200

--
 README.md| 11 +++-
 build-scripts/cassandra-deb-packaging.sh | 16 ++
 build-scripts/cassandra-rpm-packaging.sh | 17 ++
 docker/build-debs.sh | 75 ---
 docker/build-rpms.sh | 60 ++---
 docker/centos7-image.docker  |  3 +-
 docker/jessie-image.docker   |  3 +-
 7 files changed, 169 insertions(+), 16 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra-builds/blob/f3fdb2bd/README.md
--
diff --git a/README.md b/README.md
index f483b17..3b77fdd 100644
--- a/README.md
+++ b/README.md
@@ -15,14 +15,21 @@
```docker build -f docker/jessie-image.docker docker/```
* RPM:
```docker build -f docker/centos7-image.docker docker/```
+   The image will contain a clone of the Apache git repository by default. 
Using a different repository is possible by adding the `--build-arg 
CASSANDRA_GIT_URL=https://github.com/myuser/cassandra.git` parameter. All 
successive builds will be executed based on the repository cloned during docker 
image creation.
 2. Run build script through docker (specify branch, e.g. cassandra-3.0 and 
version, e.g. 3.0.11):
* Debian:
-```docker run -v `pwd`/dist:/dist `docker images -f 
label=org.cassandra.buildenv=jessie -q` /home/build/build-debs.sh ```
+```docker run --rm -v `pwd`/dist:/dist `docker images -f 
label=org.cassandra.buildenv=jessie -q` /home/build/build-debs.sh 
```
* RPM:
-```docker run -v `pwd`/dist:/dist `docker images -f 
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh  
```
+```docker run --rm -v `pwd`/dist:/dist `docker images -f 
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh 
```
 
 You should find newly created Debian and RPM packages in the `dist` directory.
 
+### Note about versioning
+
+Packages for official releases can only be build from tags. In this case, the 
tag must match the known versioning scheme. A number of sanity checks will be 
run to make sure the version matches any version defined in `build.xml` and 
`debian/changes`. But you'll have to manually keep these values in sync for 
every release.
+
+Builds based on any branch will use the version defined in either `build.xml` 
(RPM) or `debian/changes` (deb). Afterwards a snapshot indicator will be 
appended.
+
 ## Publishing packages
 
 TODO

http://git-wip-us.apache.org/repos/asf/cassandra-builds/blob/f3fdb2bd/build-scripts/cassandra-deb-packaging.sh
--
diff --git a/build-scripts/cassandra-deb-packaging.sh 
b/build-scripts/cassandra-deb-packaging.sh
new file mode 100755
index 000..4466ced
--- /dev/null
+++ b/build-scripts/cassandra-deb-packaging.sh
@@ -0,0 +1,16 @@
+#!/bin/bash -xe
+
+CASSANDRA_BUILDS_DIR="${WORKSPACE}/cassandra-builds"
+CASSANDRA_GIT_URL=$1
+CASSANDRA_BRANCH=$2
+
+# Create build images containing the build tool-chain, Java and an Apache 
Cassandra git working directory
+docker build --build-arg CASSANDRA_GIT_URL=$CASSANDRA_GIT_URL  -f 
${CASSANDRA_BUILDS_DIR}/docker/jessie-image.docker 
${CASSANDRA_BUILDS_DIR}/docker/
+
+# Create target directory for packages generated in docker run below
+mkdir -p ${CASSANDRA_BUILDS_DIR}/dist
+chmod 777 ${CASSANDRA_BUILDS_DIR}/dist
+
+# Run build script through docker (specify branch, e.g. cassandra-3.0 and 
version, e.g. 3.0.11):
+docker run --rm -v ${CASSANDRA_BUILDS_DIR}/dist:/dist `docker images -f 
label=org.cassandra.buildenv=jessie -q | awk 'NR==1'` /home/build/build-debs.sh 
$CASSANDRA_BRANCH
+

http://git-wip-us.apache.org/repos/asf/cassandra-builds/blob/f3fdb2bd/build-scripts/cassandra-rpm-packaging.sh

cassandra-builds git commit: Parameterize settings in cassandra_job_dsl_seed.groovy

2017-05-16 Thread spod 
Repository: cassandra-builds
Updated Branches:
  refs/heads/master 9e7f187a2 -> 81ab99ead


Parameterize settings in cassandra_job_dsl_seed.groovy

Closes #2


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

Branch: refs/heads/master
Commit: 81ab99ead3cc48517ff74d1a7b4379dbdc5b6971
Parents: 9e7f187
Author: Stefan Podkowinski 
Authored: Tue May 16 22:49:01 2017 +0200
Committer: Stefan Podkowinski 
Committed: Tue May 16 22:49:01 2017 +0200

--
 jenkins-dsl/cassandra_job_dsl_seed.groovy | 51 +-
 1 file changed, 41 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra-builds/blob/81ab99ea/jenkins-dsl/cassandra_job_dsl_seed.groovy
--
diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy 
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index e70e730..d47c4c2 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -6,19 +6,50 @@
 
 def jobDescription = 'Apache Cassandra DSL-generated job - DSL git repo: https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git;>cassandra-builds'
 def jdkLabel = 'JDK 1.8 (latest)'
+if(binding.hasVariable("CASSANDRA_JDK_LABEL")) {
+jdkLabel = "${CASSANDRA_JDK_LABEL}"
+}
 def slaveLabel = 'cassandra'
+if(binding.hasVariable("CASSANDRA_SLAVE_LABEL")) {
+slaveLabel = "${CASSANDRA_SLAVE_LABEL}"
+}
 // The dtest-large target needs to run on >=32G slaves, so we provide an "OR" 
list of those servers
 def largeSlaveLabel = 'cassandra6||cassandra7'
-def mainRepo = 'https://git-wip-us.apache.org/repos/asf/cassandra.git'
-def buildsRepo = 'https://git.apache.org/cassandra-builds.git'
-def dtestRepo = 'https://github.com/riptano/cassandra-dtest.git'
+if(binding.hasVariable("CASSANDRA_LARGE_SLAVE_LABEL")) {
+largeSlaveLabel = "${CASSANDRA_LARGE_SLAVE_LABEL}"
+}
+def mainRepo = "https://git-wip-us.apache.org/repos/asf/cassandra.git;
+if(binding.hasVariable("CASSANDRA_GIT_URL")) {
+mainRepo = "${CASSANDRA_GIT_URL}"
+}
+def buildsRepo = "https://git.apache.org/cassandra-builds.git;
+if(binding.hasVariable("CASSANDRA_BUILDS_GIT_URL")) {
+buildsRepo = "${CASSANDRA_BUILDS_GIT_URL}"
+}
+def buildsBranch = "master"
+if(binding.hasVariable("CASSANDRA_BUILDS_BRANCH")) {
+buildsBranch = "${CASSANDRA_BUILDS_BRANCH}"
+}
+def dtestRepo = "https://github.com/riptano/cassandra-dtest.git;
+if(binding.hasVariable("CASSANDRA_DTEST_GIT_URL")) {
+dtestRepo = "${CASSANDRA_DTEST_GIT_URL}"
+}
 def buildDescStr = 'REF = ${GIT_BRANCH}  COMMIT = ${GIT_COMMIT}'
 // Cassandra active branches
 def cassandraBranches = ['cassandra-2.2', 'cassandra-3.0', 'cassandra-3.11', 
'trunk']
+if(binding.hasVariable("CASSANDRA_BRANCHES")) {
+cassandraBranches = "${CASSANDRA_BRANCHES}".split(",")
+}
 // Ant test targets
 def testTargets = ['test', 'test-all', 'test-burn', 'test-cdc', 
'test-compression']
+if(binding.hasVariable("CASSANDRA_ANT_TEST_TARGETS")) {
+testTargets = "${CASSANDRA_ANT_TEST_TARGETS}".split(",")
+}
 // Dtest test targets
 def dtestTargets = ['dtest', 'dtest-novnode', 'dtest-offheap', 'dtest-large']
+if(binding.hasVariable("CASSANDRA_DTEST_TEST_TARGETS")) {
+dtestTargets = "${CASSANDRA_DTEST_TEST_TARGETS}".split(",")
+}
 
 
 //
@@ -62,7 +93,7 @@ job('Cassandra-template-artifacts') {
 }
 steps {
 buildDescription('', buildDescStr)
-shell("git clean -xdff ; git clone ${buildsRepo}")
+shell("git clean -xdff ; git clone -b ${buildsBranch} ${buildsRepo}")
 }
 publishers {
 archiveArtifacts('build/*.tar.gz, 
build/**/eclipse_compiler_checks.txt')
@@ -108,7 +139,7 @@ job('Cassandra-template-test') {
 }
 steps {
 buildDescription('', buildDescStr)
-shell("git clean -xdff ; git clone ${buildsRepo}")
+shell("git clean -xdff ; git clone -b ${buildsBranch} ${buildsRepo}")
 }
 publishers {
 junit {
@@ -155,7 +186,7 @@ job('Cassandra-template-dtest') {
 }
 steps {
 buildDescription('', buildDescStr)
-shell("git clean -xdff ; git clone ${buildsRepo} ; git clone 
${dtestRepo}")
+shell("git clean -xdff ; git clone -b ${buildsBranch} ${buildsRepo} ; 
git clone ${dtestRepo}")
 }
 publishers {
 archiveArtifacts('test_stdout.txt')
@@ -211,7 +242,7 @@ matrixJob('Cassandra-template-cqlsh-tests') {
 }
 steps {
 buildDescription('', buildDescStr)
-shell("git clean -xdff ;

[jira] [Updated] (CASSANDRA-13529) cassandra-stress light-weight transaction support

2017-05-16 Thread Jaydeepkumar Chovatia (JIRA) 

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

Jaydeepkumar Chovatia updated CASSANDRA-13529:
--
Attachment: (was: lwttest.yaml)

> cassandra-stress light-weight transaction support
> -
>
> Key: CASSANDRA-13529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13529
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Stress
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Minor
> Fix For: 4.x
>
> Attachments: 13529.txt, lwttest.yaml
>
>
> It would be nice to have a light-weight transaction support in 
> cassandra-stress.
> Although currently in cassandra-stress we can achieve light-weight 
> transaction partially by using static conditions like "IF col1 != null" or 
> "IF not EXIST". 
> If would be ideal to have full fledged light-weight transaction support like 
> "IF col1 = ? and col2 = ?". One way to implement is to read values from 
> Cassandra and use that in the condition so it will execute all the paxos 
> phases in Cassandra.
> Please find git link for the patch: 
> https://github.com/apache/cassandra/compare/trunk...jaydeepkumar1984:13529-trunk?expand=1



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13529) cassandra-stress light-weight transaction support

2017-05-16 Thread Jaydeepkumar Chovatia (JIRA) 

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

Jaydeepkumar Chovatia updated CASSANDRA-13529:
--
Attachment: lwttest.yaml

> cassandra-stress light-weight transaction support
> -
>
> Key: CASSANDRA-13529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13529
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Stress
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Minor
> Fix For: 4.x
>
> Attachments: 13529.txt, lwttest.yaml
>
>
> It would be nice to have a light-weight transaction support in 
> cassandra-stress.
> Although currently in cassandra-stress we can achieve light-weight 
> transaction partially by using static conditions like "IF col1 != null" or 
> "IF not EXIST". 
> If would be ideal to have full fledged light-weight transaction support like 
> "IF col1 = ? and col2 = ?". One way to implement is to read values from 
> Cassandra and use that in the condition so it will execute all the paxos 
> phases in Cassandra.
> Please find git link for the patch: 
> https://github.com/apache/cassandra/compare/trunk...jaydeepkumar1984:13529-trunk?expand=1



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13529) cassandra-stress light-weight transaction support

2017-05-16 Thread Jaydeepkumar Chovatia (JIRA) 

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

Jaydeepkumar Chovatia updated CASSANDRA-13529:
--
Attachment: lwttest.yaml

Sample cassandra-stress yaml file with lwt transaction support

> cassandra-stress light-weight transaction support
> -
>
> Key: CASSANDRA-13529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13529
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Stress
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Minor
> Fix For: 4.x
>
> Attachments: 13529.txt, lwttest.yaml
>
>
> It would be nice to have a light-weight transaction support in 
> cassandra-stress.
> Although currently in cassandra-stress we can achieve light-weight 
> transaction partially by using static conditions like "IF col1 != null" or 
> "IF not EXIST". 
> If would be ideal to have full fledged light-weight transaction support like 
> "IF col1 = ? and col2 = ?". One way to implement is to read values from 
> Cassandra and use that in the condition so it will execute all the paxos 
> phases in Cassandra.
> Please find git link for the patch: 
> https://github.com/apache/cassandra/compare/trunk...jaydeepkumar1984:13529-trunk?expand=1



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-12847) cqlsh DESCRIBE output doesn't properly quote index names

2017-05-16 Thread Sam Tunnicliffe (JIRA) 

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

Sam Tunnicliffe commented on CASSANDRA-12847:
-

Bummer, I ran everything in {{cqlsh_test.py}} before committing, but no 
{{cqlshlib}}, I'll look at those failures.

> cqlsh DESCRIBE output doesn't properly quote index names
> 
>
> Key: CASSANDRA-12847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12847
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>  Labels: cqlsh
> Fix For: 3.0.14, 3.11.0, 4.0
>
>
> CASSANDRA-8365 fixed the CQL grammar so that quoting index names preserves 
> case. The output of DESCRIBE in cqlsh wasn't updated however so this doesn't 
> round-trip properly. 



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-12847) cqlsh DESCRIBE output doesn't properly quote index names

2017-05-16 Thread Michael Shuler (JIRA) 

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

Michael Shuler commented on CASSANDRA-12847:


It appears that a number of the in-tree cqlshlib tests failed after this 
commit. The dtests look like they were merged and passed successfully on this 
run.
http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_cqlsh_tests/34/testReport/

I'm re-running this job to see if it reproduces, and we'll go from there!

> cqlsh DESCRIBE output doesn't properly quote index names
> 
>
> Key: CASSANDRA-12847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12847
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>  Labels: cqlsh
> Fix For: 3.0.14, 3.11.0, 4.0
>
>
> CASSANDRA-8365 fixed the CQL grammar so that quoting index names preserves 
> case. The output of DESCRIBE in cqlsh wasn't updated however so this doesn't 
> round-trip properly. 



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13530) GroupCommitLogService

2017-05-16 Thread Ariel Weisberg (JIRA) 

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

Ariel Weisberg commented on CASSANDRA-13530:


If you double {{concurrent_writes}} in cassandra.yaml what does that do at 256 
concurrent threads?

I would be more comfortable with the results if they were generated in a more 
realistic way. Fix concurrency at 256 and use a Guava rate limiter to generate 
requests at a fixed rate and then record the resulting latency and throughput 
in an HdrHistogram. I think that will produce a more complete picture regarding 
latency and throughput.

> GroupCommitLogService
> -
>
> Key: CASSANDRA-13530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13530
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Yuji Ito
>Assignee: Yuji Ito
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
> Attachments: groupCommit22.patch, groupCommit30.patch, 
> groupCommit3x.patch, MicroRequestThread.java
>
>
> I propose a new CommitLogService, GroupCommitLogService, to improve the 
> throughput when lots of requests are received.
> It improved the throughput by maximum 94%.
> I'd like to discuss about this CommitLogService.
> Currently, we can select either 2 CommitLog services; Periodic and Batch.
> In Periodic, we might lose some commit log which hasn't written to the disk.
> In Batch, we can write commit log to the disk every time. The size of commit 
> log to write is too small (< 4KB). When high concurrency, these writes are 
> gathered and persisted to the disk at once. But, when insufficient 
> concurrency, many small writes are issued and the performance decreases due 
> to the latency of the disk. Even if you use SSD, processes of many IO 
> commands decrease the performance.
> GroupCommitLogService writes some commitlog to the disk at once.
> The patch adds GroupCommitLogService (It is enabled by setting 
> `commitlog_sync` and `commitlog_sync_group_window_in_ms` in cassandra.yaml).
> The difference from Batch is just only waiting for the semaphore.
> By waiting for the semaphore, some writes for commit logs are executed at the 
> same time.
> In GroupCommitLogService, the latency becomes worse if the there is no 
> concurrency.
> I measured the performance with my microbench (MicroRequestThread.java) by 
> increasing the number of threads.The cluster has 3 nodes (Replication factor: 
> 3). Each nodes is AWS EC2 m4.large instance + 200IOPS io1 volume.
> The result is as below. The GroupCommitLogService with 10ms window improved 
> update with Paxos by 94% and improved select with Paxos by 76%.
> h6. SELECT / sec
> ||\# of threads||Batch 2ms||Group 10ms||
> |1|192|103|
> |2|163|212|
> |4|264|416|
> |8|454|800|
> |16|744|1311|
> |32|1151|1481|
> |64|1767|1844|
> |128|2949|3011|
> |256|4723|5000|
> h6. UPDATE / sec
> ||\# of threads||Batch 2ms||Group 10ms||
> |1|45|26|
> |2|39|51|
> |4|58|102|
> |8|102|198|
> |16|167|213|
> |32|289|295|
> |64|544|548|
> |128|1046|1058|
> |256|2020|2061|



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13533) ColumnIdentifier object size wrong when tables are not flushed

2017-05-16 Thread Eduard Tudenhoefner (JIRA) 

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

Eduard Tudenhoefner edited comment on CASSANDRA-13533 at 5/16/17 4:32 PM:
--

Branch: https://github.com/nastra/cassandra/tree/CASSANDRA-13533-30
Tests: https://circleci.com/gh/nastra/cassandra/tree/CASSANDRA-13533-30


was (Author: eduard.tudenhoefner):
Branch: https://github.com/nastra/cassandra/tree/CASSANDRA-13533-30

> ColumnIdentifier object size wrong when tables are not flushed
> --
>
> Key: CASSANDRA-13533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13533
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
> Fix For: 3.0.14, 3.11.0, 4.0
>
>
> It turns out that the object size of {{ColumnIdentifier}} is wrong when 
> *cassandra.test.flush_local_schema_changes: false*. This looks like stuff is 
> being wrongly reused when no flush is happening.
> We only noticed this because we were using the prepared stmt cache and 
> noticed that prepared statements would account for *1-6mb* when 
> *cassandra.test.flush_local_schema_changes: false*. With 
> *cassandra.test.flush_local_schema_changes: true* (which is the default) 
> those would be around *5000 bytes*.
> Attached is a test that reproduces the problem and also a fix.
> Also after talking to [~jkni] / [~blerer] we shouldn't probably take 
> {{ColumnDefinition}} into account when measuring object sizes with 
> {{MemoryMeter}}



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13533) ColumnIdentifier object size wrong when tables are not flushed

2017-05-16 Thread Eduard Tudenhoefner (JIRA) 

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

Eduard Tudenhoefner updated CASSANDRA-13533:

Fix Version/s: 4.0
   3.11.0
   3.0.14
Reproduced In: 3.0.13
   Status: Patch Available  (was: In Progress)

> ColumnIdentifier object size wrong when tables are not flushed
> --
>
> Key: CASSANDRA-13533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13533
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
> Fix For: 3.0.14, 3.11.0, 4.0
>
>
> It turns out that the object size of {{ColumnIdentifier}} is wrong when 
> *cassandra.test.flush_local_schema_changes: false*. This looks like stuff is 
> being wrongly reused when no flush is happening.
> We only noticed this because we were using the prepared stmt cache and 
> noticed that prepared statements would account for *1-6mb* when 
> *cassandra.test.flush_local_schema_changes: false*. With 
> *cassandra.test.flush_local_schema_changes: true* (which is the default) 
> those would be around *5000 bytes*.
> Attached is a test that reproduces the problem and also a fix.
> Also after talking to [~jkni] / [~blerer] we shouldn't probably take 
> {{ColumnDefinition}} into account when measuring object sizes with 
> {{MemoryMeter}}



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13533) ColumnIdentifier object size wrong when tables are not flushed

2017-05-16 Thread Eduard Tudenhoefner (JIRA) 

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

Eduard Tudenhoefner commented on CASSANDRA-13533:
-

Branch: https://github.com/nastra/cassandra/tree/CASSANDRA-13533-30

> ColumnIdentifier object size wrong when tables are not flushed
> --
>
> Key: CASSANDRA-13533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13533
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
>
> It turns out that the object size of {{ColumnIdentifier}} is wrong when 
> *cassandra.test.flush_local_schema_changes: false*. This looks like stuff is 
> being wrongly reused when no flush is happening.
> We only noticed this because we were using the prepared stmt cache and 
> noticed that prepared statements would account for *1-6mb* when 
> *cassandra.test.flush_local_schema_changes: false*. With 
> *cassandra.test.flush_local_schema_changes: true* (which is the default) 
> those would be around *5000 bytes*.
> Attached is a test that reproduces the problem and also a fix.
> Also after talking to [~jkni] / [~blerer] we shouldn't probably take 
> {{ColumnDefinition}} into account when measuring object sizes with 
> {{MemoryMeter}}



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13533) ColumnIdentifier object size wrong when tables are not flushed

2017-05-16 Thread Eduard Tudenhoefner (JIRA) 

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

Eduard Tudenhoefner updated CASSANDRA-13533:

Description: 
It turns out that the object size of {{ColumnIdentifier}} is wrong when 
*cassandra.test.flush_local_schema_changes: false*. This looks like stuff is 
being wrongly reused when no flush is happening.

We only noticed this because we were using the prepared stmt cache and noticed 
that prepared statements would account for *1-6mb* when 
*cassandra.test.flush_local_schema_changes: false*. With 
*cassandra.test.flush_local_schema_changes: true* (which is the default) those 
would be around *5000 bytes*.

Attached is a test that reproduces the problem and also a fix.

Also after talking to [~jkni] / [~blerer] we shouldn't probably take 
{{ColumnDefinition}} into account when measuring object sizes with 
{{MemoryMeter}}


  was:
It turns out that the object size of {{ColumnIdentifier}} is wrong when 
*cassandra.test.flush_local_schema_changes: false*. This looks like stuff is 
being wrongly reused when no flush is happening.

We only noticed this because we were using the prepared stmt cache and noticed 
that prepared statements would account for *1-6mb* when 
*cassandra.test.flush_local_schema_changes: false*. With 
*cassandra.test.flush_local_schema_changes: true* (which is the default) those 
would be around *5000 bytes*.

Attached is a test that reproduces the problem and also a fix.





> ColumnIdentifier object size wrong when tables are not flushed
> --
>
> Key: CASSANDRA-13533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13533
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
>
> It turns out that the object size of {{ColumnIdentifier}} is wrong when 
> *cassandra.test.flush_local_schema_changes: false*. This looks like stuff is 
> being wrongly reused when no flush is happening.
> We only noticed this because we were using the prepared stmt cache and 
> noticed that prepared statements would account for *1-6mb* when 
> *cassandra.test.flush_local_schema_changes: false*. With 
> *cassandra.test.flush_local_schema_changes: true* (which is the default) 
> those would be around *5000 bytes*.
> Attached is a test that reproduces the problem and also a fix.
> Also after talking to [~jkni] / [~blerer] we shouldn't probably take 
> {{ColumnDefinition}} into account when measuring object sizes with 
> {{MemoryMeter}}



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13533) ColumnIdentifier object size wrong when tables are not flushed

2017-05-16 Thread Eduard Tudenhoefner (JIRA) 

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

Eduard Tudenhoefner updated CASSANDRA-13533:

Since Version: 3.0.0

> ColumnIdentifier object size wrong when tables are not flushed
> --
>
> Key: CASSANDRA-13533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13533
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
>
> It turns out that the object size of {{ColumnIdentifier}} is wrong when 
> *cassandra.test.flush_local_schema_changes: false*. This looks like stuff is 
> being wrongly reused when no flush is happening.
> We only noticed this because we were using the prepared stmt cache and 
> noticed that prepared statements would account for *1-6mb* when 
> *cassandra.test.flush_local_schema_changes: false*. With 
> *cassandra.test.flush_local_schema_changes: true* (which is the default) 
> those would be around *5000 bytes*.
> Attached is a test that reproduces the problem and also a fix.



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13533) ColumnIdentifier object size wrong when tables are not flushed

2017-05-16 Thread Eduard Tudenhoefner (JIRA) 
Eduard Tudenhoefner created CASSANDRA-13533:
---

 Summary: ColumnIdentifier object size wrong when tables are not 
flushed
 Key: CASSANDRA-13533
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13533
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Eduard Tudenhoefner
Assignee: Eduard Tudenhoefner


It turns out that the object size of {{ColumnIdentifier}} is wrong when 
*cassandra.test.flush_local_schema_changes: false*. This looks like stuff is 
being wrongly reused when no flush is happening.

We only noticed this because we were using the prepared stmt cache and noticed 
that prepared statements would account for *1-6mb* when 
*cassandra.test.flush_local_schema_changes: false*. With 
*cassandra.test.flush_local_schema_changes: true* (which is the default) those 
would be around *5000 bytes*.

Attached is a test that reproduces the problem and also a fix.






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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13496) table with lots of column ( tens of thousands columns), system is very slow

2017-05-16 Thread Jeff Jirsa (JIRA) 

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

Jeff Jirsa edited comment on CASSANDRA-13496 at 5/16/17 3:52 PM:
-

The debug messages are just debug messages, not indicative of a problem. Can 
you quantify "very slow"? 

In general, a table with tens of thousands of columns of any kind sounds like 
an awful data model, and it would benefit you greatly to redesign it.  Looking 
at your schema, it's actually thousands of lists, which is even worse. 

This is a horribly broken data model, and incredibly unlikely to work well in 
cassandra at any time in the next 2-3 years. 


was (Author: jjirsa):
The debug messages are just debug messages, not indicative of a problem. Can 
you quantify "very slow"? 

In general, a table with tens of thousands of columns sounds like an awful data 
model, and it would benefit you greatly to redesign it. 

> table with lots of column ( tens of thousands columns), system is very slow 
> 
>
> Key: CASSANDRA-13496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13496
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: linux redhat 6.5 cassandra 3.10 using 2i
> cpu : 4 core , memory: 16G  . 5 servers
> using gocql client
>Reporter: lizg
>Priority: Minor
>  Labels: usability
> Attachments: debug.log, sql.txt
>
>
> In debug.log there are lots of 
> DEBUG [COMMIT-LOG-ALLOCATOR] 2017-05-04 08:54:35,769 
> AbstractCommitLogSegmentManager.java:107 - No segments in reserve; creating a 
> fresh one
> DEBUG [MemtablePostFlush:54] 2017-05-04 08:49:19,699 
> AbstractCommitLogSegmentManager.java:329 - Segment 
> CommitLogSegment(/home/matrix/cassandra/commitlog/CommitLog-6-1493809341337.log)
>  is no longer active and will be deleted now



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13496) table with lots of column ( tens of thousands columns), system is very slow

2017-05-16 Thread Jeff Jirsa (JIRA) 

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

Jeff Jirsa edited comment on CASSANDRA-13496 at 5/16/17 3:51 PM:
-

The debug messages are just debug messages, not indicative of a problem. Can 
you quantify "very slow"? 

In general, a table with tens of thousands of columns sounds like an awful data 
model, and it would benefit you greatly to redesign it. 


was (Author: jjirsa):
The debug messages are just debug messages, not indicative of a problem. Can 
you quantify "very slow"? 


> table with lots of column ( tens of thousands columns), system is very slow 
> 
>
> Key: CASSANDRA-13496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13496
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: linux redhat 6.5 cassandra 3.10 using 2i
> cpu : 4 core , memory: 16G  . 5 servers
> using gocql client
>Reporter: lizg
>Priority: Minor
>  Labels: usability
> Attachments: debug.log, sql.txt
>
>
> In debug.log there are lots of 
> DEBUG [COMMIT-LOG-ALLOCATOR] 2017-05-04 08:54:35,769 
> AbstractCommitLogSegmentManager.java:107 - No segments in reserve; creating a 
> fresh one
> DEBUG [MemtablePostFlush:54] 2017-05-04 08:49:19,699 
> AbstractCommitLogSegmentManager.java:329 - Segment 
> CommitLogSegment(/home/matrix/cassandra/commitlog/CommitLog-6-1493809341337.log)
>  is no longer active and will be deleted now



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13216) testall failure in org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages

2017-05-16 Thread Michael Kjellman (JIRA) 

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

Michael Kjellman updated CASSANDRA-13216:
-
Status: Ready to Commit  (was: Patch Available)

> testall failure in 
> org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages
> 
>
> Key: CASSANDRA-13216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13216
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Alex Petrov
>  Labels: test-failure, testall
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: TEST-org.apache.cassandra.net.MessagingServiceTest.log, 
> TEST-org.apache.cassandra.net.MessagingServiceTest.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.11_testall/81/testReport/org.apache.cassandra.net/MessagingServiceTest/testDroppedMessages
> {code}
> Error Message
> expected:<... dropped latency: 27[30 ms and Mean cross-node dropped latency: 
> 2731] ms> but was:<... dropped latency: 27[28 ms and Mean cross-node dropped 
> latency: 2730] ms>
> {code}{code}
> Stacktrace
> junit.framework.AssertionFailedError: expected:<... dropped latency: 27[30 ms 
> and Mean cross-node dropped latency: 2731] ms> but was:<... dropped latency: 
> 27[28 ms and Mean cross-node dropped latency: 2730] ms>
>   at 
> org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages(MessagingServiceTest.java:83)
> {code}



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13216) testall failure in org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages

2017-05-16 Thread Michael Kjellman (JIRA) 

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

Michael Kjellman commented on CASSANDRA-13216:
--

Looks great! +1 Thanks Alex

> testall failure in 
> org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages
> 
>
> Key: CASSANDRA-13216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13216
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Alex Petrov
>  Labels: test-failure, testall
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: TEST-org.apache.cassandra.net.MessagingServiceTest.log, 
> TEST-org.apache.cassandra.net.MessagingServiceTest.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.11_testall/81/testReport/org.apache.cassandra.net/MessagingServiceTest/testDroppedMessages
> {code}
> Error Message
> expected:<... dropped latency: 27[30 ms and Mean cross-node dropped latency: 
> 2731] ms> but was:<... dropped latency: 27[28 ms and Mean cross-node dropped 
> latency: 2730] ms>
> {code}{code}
> Stacktrace
> junit.framework.AssertionFailedError: expected:<... dropped latency: 27[30 ms 
> and Mean cross-node dropped latency: 2731] ms> but was:<... dropped latency: 
> 27[28 ms and Mean cross-node dropped latency: 2730] ms>
>   at 
> org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages(MessagingServiceTest.java:83)
> {code}



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13496) table with lots of column ( tens of thousands columns), system is very slow

2017-05-16 Thread Joshua McKenzie (JIRA) 

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

Joshua McKenzie updated CASSANDRA-13496:

Labels: usability  (was: )

> table with lots of column ( tens of thousands columns), system is very slow 
> 
>
> Key: CASSANDRA-13496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13496
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: linux redhat 6.5 cassandra 3.10 using 2i
> cpu : 4 core , memory: 16G  . 5 servers
> using gocql client
>Reporter: lizg
>Priority: Minor
>  Labels: usability
> Attachments: debug.log, sql.txt
>
>
> In debug.log there are lots of 
> DEBUG [COMMIT-LOG-ALLOCATOR] 2017-05-04 08:54:35,769 
> AbstractCommitLogSegmentManager.java:107 - No segments in reserve; creating a 
> fresh one
> DEBUG [MemtablePostFlush:54] 2017-05-04 08:49:19,699 
> AbstractCommitLogSegmentManager.java:329 - Segment 
> CommitLogSegment(/home/matrix/cassandra/commitlog/CommitLog-6-1493809341337.log)
>  is no longer active and will be deleted now



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13513) Getting java.lang.AssertionError after upgrade from Cassandra 2.1.17.1428 to 3.0.8

2017-05-16 Thread Alex Petrov (JIRA) 

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

Alex Petrov updated CASSANDRA-13513:

Description: 
Hi,
While querying Cassandra table using DBeaver or using DataStax Node.js Driver 
getting below error. 
{code}
WARN  [SharedPool-Worker-2] 2017-05-09 12:55:18,654  
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:228)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:218)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137) 
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:300)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76) 
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:320) 
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1796)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2466)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_101]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
 [cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
{code}

Query used is 

{code}
select * from dynocloud.user_info where company_name='DS' allow filtering;
{code} 

This query returns data when run in cql shell. 
Also if we give limit 100 to the same query or change the value to 
company_name, the query returns results. The index definition is 
{code} 
CREATE INDEX company_name_userindex ON dynocloud.user_info (company_name);
{code} 
Thanks,
Anuja Mandlecha

  was:
Hi,
While querying Cassandra table using DBeaver or using DataStax Node.js Driver 
getting below error. 
WARN  [SharedPool-Worker-2] 2017-05-09 12:55:18,654  
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:228)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:218)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137) 
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
 ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)

[jira] [Updated] (CASSANDRA-13526) nodetool cleanup on KS with no replicas should remove old data, not silently complete

2017-05-16 Thread Joshua McKenzie (JIRA) 

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

Joshua McKenzie updated CASSANDRA-13526:

Labels: usability  (was: )

> nodetool cleanup on KS with no replicas should remove old data, not silently 
> complete
> -
>
> Key: CASSANDRA-13526
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13526
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jeff Jirsa
>  Labels: usability
>
> From the user list:
> https://lists.apache.org/thread.html/5d49cc6bbc6fd2e5f8b12f2308a3e24212a55afbb441af5cb8cd4167@%3Cuser.cassandra.apache.org%3E
> If you have a multi-dc cluster, but some keyspaces not replicated to a given 
> DC, you'll be unable to run cleanup on those keyspaces in that DC, because 
> [the cleanup code will see no ranges and exit 
> early|https://github.com/apache/cassandra/blob/4cfaf85/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L427-L441]



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-12993) License headers missing in some source files

2017-05-16 Thread Stefan Podkowinski (JIRA) 

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

Stefan Podkowinski reassigned CASSANDRA-12993:
--

Assignee: Stefan Podkowinski

> License headers missing in some source files
> 
>
> Key: CASSANDRA-12993
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12993
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Tomas Repik
>Assignee: Stefan Podkowinski
> Fix For: 4.0
>
>
> The following source files are without license headers:
>   doc/source/_static/extra.css
>   src/java/org/apache/cassandra/db/commitlog/IntervalSet.java
>   src/java/org/apache/cassandra/utils/IntegerInterval.java
>   test/unit/org/apache/cassandra/db/commitlog/CommitLogCQLTest.java
>   test/unit/org/apache/cassandra/utils/IntegerIntervalsTest.java
>   tools/stress/src/org/apache/cassandra/stress/WorkManager.java
> Could you please confirm the licensing of code and/or content/s, and add 
> license headers?



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13528) nodetool describeclusters shows different snitch info as to what is configured.

2017-05-16 Thread Joshua McKenzie (JIRA) 

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

Joshua McKenzie updated CASSANDRA-13528:

Labels: lhf  (was: )

> nodetool describeclusters shows different snitch info as to what is 
> configured.
> ---
>
> Key: CASSANDRA-13528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13528
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paul Villacorta
>Priority: Minor
>  Labels: lhf
> Attachments: Screen Shot 2017-05-12 at 14.15.04.png
>
>
> I couldn't find any similar issue as this one so I'm creating one.
> I noticed that doing nodetool describecluster shows a different Snitch 
> Information as to what is being set in the configuration file.
> My setup is hosted in AWS and I am using Ec2Snitch.
> cassandra@cassandra3$ nodetool describecluster
> Cluster Information:
>   Name: testv3
>   Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
>   Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>   Schema versions:
>   fc6e8656-ee7a-341b-9782-b569d1fd1a51: 
> [10.0.3.61,10.0.3.62,10.0.3.63]
> I checked via MX4J and it shows the same, I haven't verified tho using a 
> different Snitch and I am using 2.2.6 above and 3.0.X 



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13532) sstabledump reports incorrect usage for argument order

2017-05-16 Thread Joshua McKenzie (JIRA) 

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

Joshua McKenzie updated CASSANDRA-13532:

Labels: lhf  (was: )

> sstabledump reports incorrect usage for argument order
> --
>
> Key: CASSANDRA-13532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13532
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Ian Ilsley
>Priority: Minor
>  Labels: lhf
>
> sstabledump usage reports 
> {{usage: sstabledump  }}
> However the actual usage is 
> {{sstabledump   }}



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12888) Incremental repairs broken for MVs and CDC

2017-05-16 Thread Paulo Motta (JIRA) 

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

Paulo Motta updated CASSANDRA-12888:

Status: Open  (was: Patch Available)

> Incremental repairs broken for MVs and CDC
> --
>
> Key: CASSANDRA-12888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12888
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Stefan Podkowinski
>Assignee: Benjamin Roth
>Priority: Critical
> Fix For: 3.0.x, 3.11.x
>
>
> SSTables streamed during the repair process will first be written locally and 
> afterwards either simply added to the pool of existing sstables or, in case 
> of existing MVs or active CDC, replayed on mutation basis:
> As described in {{StreamReceiveTask.OnCompletionRunnable}}:
> {quote}
> We have a special path for views and for CDC.
> For views, since the view requires cleaning up any pre-existing state, we 
> must put all partitions through the same write path as normal mutations. This 
> also ensures any 2is are also updated.
> For CDC-enabled tables, we want to ensure that the mutations are run through 
> the CommitLog so they can be archived by the CDC process on discard.
> {quote}
> Using the regular write path turns out to be an issue for incremental 
> repairs, as we loose the {{repaired_at}} state in the process. Eventually the 
> streamed rows will end up in the unrepaired set, in contrast to the rows on 
> the sender site moved to the repaired set. The next repair run will stream 
> the same data back again, causing rows to bounce on and on between nodes on 
> each repair.
> See linked dtest on steps to reproduce. An example for reproducing this 
> manually using ccm can be found 
> [here|https://gist.github.com/spodkowinski/2d8e0408516609c7ae701f2bf1e515e8]



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-12888) Incremental repairs broken for MVs and CDC

2017-05-16 Thread Paulo Motta (JIRA) 

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

Paulo Motta commented on CASSANDRA-12888:
-

First of all thank you for your effort on this issue and sorry for the delay. I 
had an initial look at the patch and while I didn't spot any immediate flaws, 
it is not clear from looking at the code alone if this is not going to have any 
unintended repercussions in some other component (commit log archiving, 
memtable lifecyle/flushing, read/write path) since this is changing a core 
assumption that a given CF/table has a single active memtable (or at most 2, 
during flush) to having multiple active memtables. While in an ideal world 
correctness would be ensured by tests, we know well our test coverage is far 
from ideal so we need to make sure the approach is well discussed and all edge 
cases understood before jumping into actual code.

One way to facilitate communication in changes like this is through a design 
doc, which is not generally required for small changes, but since we're 
modifying a core component it is important to spell out all the details in a 
design doc to make sure we're covering everything and to communicate the change 
to interested parties for feedback without exposing them to actual code. With 
this said, it would be great if you could prepare a short design doc with 
proposed changes and justification, how the memtable and flushing lifecycle is 
affected by this, impacted areas, API changes/additions, test plan before we 
proceed.

Overall I think you are on the right path but your approach needs some 
adjustments. See comments below:
* I think explicitly managing the repaired memtable lifecycle from the repair 
job is less prone to errors/leaks than let the memtable be created on demand 
when the mutation is being applied and removed organically by automatic flush. 
My suggestion would be to create the memtable at the start of the repair job 
when necessary, append mutations to it and then flush/remove the additional 
memtable at the end of the job.
* In order for this to play along well with 
[CASSANDRA-9143|https://issues.apache.org/jira/browse/CASSANDRA-9143], the 
mutation would somehow need to include the repair session id which would be 
used to retrieve the repairedAt from {{ActiveRepairService}}. In this 
arrangement we would keep a memtable per active repair session to ensure 
mutations from the same job are flushed to the same sstable. 
{{Tracker.getMemtableFor}} would fetch the right memtable for that repair 
session id, and return the ordinary unrepaired memtable if there is not 
memtable created for that repair session id (and probably log a warning).
* You modified flush to operate on all memtables of a given table, but we 
probably need to keep flush to a single memtable since we don't want to flush 
all memtables every time. For instance, if {{memtable_cleanup_threshold}} is 
reached you will want to flush only the largest memtable, not all memtables for 
a given table. Memtable will have different creation times, so you will only 
want to flush the expired memtable and not all memtables for a given table. For 
repair you will only want to flush unrepaired memtables. Sometimes you will 
need to flush all memtables of a given table (such as nodetool flush), but not 
every time. With this we keep the flush lifecyle pretty much the same it is 
today, there will be at most 2 active memtables for unrepaired data and at most 
2 active memtables for each repair session (one being flushed and maybe its 
replacement), what will facilitate understanding and reduce surface to 
unintended side-effects. All of these changes need to be spelled out on the 
design doc as well as javadoc to make sure it's clearly communicated.

[~krummas] [~bdeggleston] Does the above sound reasonable or do you have any 
other suggestions or remarks? Marcus, is this more or less how you planned to 
add repaired memtables on CASSANDRA-8911 or did you have something else in mind?



> Incremental repairs broken for MVs and CDC
> --
>
> Key: CASSANDRA-12888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12888
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Stefan Podkowinski
>Assignee: Benjamin Roth
>Priority: Critical
> Fix For: 3.0.x, 3.11.x
>
>
> SSTables streamed during the repair process will first be written locally and 
> afterwards either simply added to the pool of existing sstables or, in case 
> of existing MVs or active CDC, replayed on mutation basis:
> As described in {{StreamReceiveTask.OnCompletionRunnable}}:
> {quote}
> We have a special path for views and for CDC.
> For views, since the view requires cleaning up any pre-existing state, we

[jira] [Issue Comment Deleted] (CASSANDRA-8273) Allow filtering queries can return stale data

2017-05-16 Thread Alex Petrov (JIRA) 

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

Alex Petrov updated CASSANDRA-8273:
---
Comment: was deleted

(was: Should we start working on moving filtering to the coordinator right 
away, or should we maybe wait for the {{QueryPlanner}} (which is at the moment 
not really planned)?)

> Allow filtering queries can return stale data
> -
>
> Key: CASSANDRA-8273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8273
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Andrés de la Peña
>
> Data filtering is done replica side. That means that a single replica with 
> stale data may make the whole query return that stale data.
> For instance, consider 3 replicas A, B and C, and the following situation:
> {noformat}
> CREATE TABLE test (k int PRIMARY KEY, v1 text, v2 int);
> CREATE INDEX ON test(v1);
> INSERT INTO test(k, v1, v2) VALUES (0, 'foo', 1);
> {noformat}
> with every replica up to date. Now, suppose that the following queries are 
> done at {{QUORUM}}:
> {noformat}
> UPDATE test SET v2 = 2 WHERE k = 0;
> SELECT * FROM test WHERE v1 = 'foo' AND v2 = 1;
> {noformat}
> then, if A and B acknowledge the insert but C respond to the read before 
> having applied the insert, then the now stale result will be returned. Let's 
> note that this is a problem related to filtering, not 2ndary indexes.
> This issue share similarity with CASSANDRA-8272 but contrarily to that former 
> issue, I'm not sure how to fix it. Obviously, moving the filtering to the 
> coordinator would remove that problem, but doing so would, on top of not 
> being trivial to implmenent, have serious performance impact since we can't 
> know in advance how much data will be filtered and we may have to redo query 
> to replica multiple times.



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-8273) Allow filtering queries can return stale data

2017-05-16 Thread Alex Petrov (JIRA) 

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

Alex Petrov commented on CASSANDRA-8273:


Should we start working on moving filtering to the coordinator right away, or 
should we maybe wait for the {{QueryPlanner}} (which is at the moment not 
really planned)?

> Allow filtering queries can return stale data
> -
>
> Key: CASSANDRA-8273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8273
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Andrés de la Peña
>
> Data filtering is done replica side. That means that a single replica with 
> stale data may make the whole query return that stale data.
> For instance, consider 3 replicas A, B and C, and the following situation:
> {noformat}
> CREATE TABLE test (k int PRIMARY KEY, v1 text, v2 int);
> CREATE INDEX ON test(v1);
> INSERT INTO test(k, v1, v2) VALUES (0, 'foo', 1);
> {noformat}
> with every replica up to date. Now, suppose that the following queries are 
> done at {{QUORUM}}:
> {noformat}
> UPDATE test SET v2 = 2 WHERE k = 0;
> SELECT * FROM test WHERE v1 = 'foo' AND v2 = 1;
> {noformat}
> then, if A and B acknowledge the insert but C respond to the read before 
> having applied the insert, then the now stale result will be returned. Let's 
> note that this is a problem related to filtering, not 2ndary indexes.
> This issue share similarity with CASSANDRA-8272 but contrarily to that former 
> issue, I'm not sure how to fix it. Obviously, moving the filtering to the 
> coordinator would remove that problem, but doing so would, on top of not 
> being trivial to implmenent, have serious performance impact since we can't 
> know in advance how much data will be filtered and we may have to redo query 
> to replica multiple times.



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13216) testall failure in org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages

2017-05-16 Thread Alex Petrov (JIRA) 

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

Alex Petrov edited comment on CASSANDRA-13216 at 5/16/17 11:55 AM:
---

Oh yes I already did, was just waiting for CI results (which by now came clean):

||[3.11|https://github.com/ifesdjeen/cassandra/tree/13216-followup-3.11]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-13216-followup-3.11-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-13216-followup-3.11-dtest/]|
||[trunk|https://github.com/ifesdjeen/cassandra/tree/13216-followup-trunk]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-13216-followup-trunk-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-13216-followup-trunk-dtest/]|


was (Author: ifesdjeen):
Oh yes I already did, was just waiting for CI results (which by now came clean)!

> testall failure in 
> org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages
> 
>
> Key: CASSANDRA-13216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13216
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Alex Petrov
>  Labels: test-failure, testall
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: TEST-org.apache.cassandra.net.MessagingServiceTest.log, 
> TEST-org.apache.cassandra.net.MessagingServiceTest.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.11_testall/81/testReport/org.apache.cassandra.net/MessagingServiceTest/testDroppedMessages
> {code}
> Error Message
> expected:<... dropped latency: 27[30 ms and Mean cross-node dropped latency: 
> 2731] ms> but was:<... dropped latency: 27[28 ms and Mean cross-node dropped 
> latency: 2730] ms>
> {code}{code}
> Stacktrace
> junit.framework.AssertionFailedError: expected:<... dropped latency: 27[30 ms 
> and Mean cross-node dropped latency: 2731] ms> but was:<... dropped latency: 
> 27[28 ms and Mean cross-node dropped latency: 2730] ms>
>   at 
> org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages(MessagingServiceTest.java:83)
> {code}



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13444) Fast and garbage-free Streaming Histogram

2017-05-16 Thread Fuud (JIRA) 

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

Fuud commented on CASSANDRA-13444:
--

Thank you for review.
I'll handle issues in near future.

> Fast and garbage-free Streaming Histogram
> -
>
> Key: CASSANDRA-13444
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13444
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Fuud
>Assignee: Fuud
> Fix For: 4.x
>
> Attachments: results.csv, results.xlsx
>
>
> StreamingHistogram is cause of high cpu usage and GC pressure.
> It was improved at CASSANDRA-13038 by introducing intermediate buffer to try 
> accumulate different values into the big map before merging them into smaller 
> one.
> But there was not enought for TTL's distributed within large time. Rounding 
> (also introduced at 13038) can help but it reduce histogram precision 
> specially in case where TTL's does not distributed uniformly.
> There are several improvements that can help to reduce cpu and gc usage. Them 
> all included in the pool-request as separate revisions thus you can test them 
> independently.
> Improvements list:
> # Use Map.computeIfAbsent instead of get->checkIfNull->put chain. In this way 
> "add-or-accumulate" operation takes one map operation instead of two. But 
> this method (default-defined in interface Map) is overriden in HashMap but 
> not in TreeMap. Thus I changed spool type to HashMap.
> # As we round incoming values to _roundSeconds_ we can also round value on 
> merge. It will enlarge hit rate for bin operations.
> # Because we inserted only integers into Histogram and rounding values to 
> integers we can use *int* type everywhere.
> # Histogram takes huge amount of time merging values. In merge method largest 
> amount of time taken by finding nearest points. It can be eliminated by 
> holding additional TreeSet with differences, sorted from smalest to greatest.
> # Because we know max size of _bin_ and _differences_ maps we can replace 
> them with sorted arrays. Search can be done with _Arrays.binarySearch_ and 
> insertion/deletions can be done by _System.arraycopy_. Also it helps to merge 
> some operations into one.
> # Because spool map is also limited we can replace it with open address 
> primitive map. It's finaly reduce allocation rate to zero.
> You can see gain given by each step in the attached file. First number is 
> time for one benchmark invocation and second - is allocation rate in Mb per 
> operation.
> Dependends of payload time is reduced up to 90%.
> Overall gain:
> |.|.|Payload/SpoolSize|.|.|.|% from original
> |.|.|.|original|.|optimized|
> |.|.|secondInMonth/0|.|.|.|
> |time ms/op|.|.|10747,684|.|5545,063|51,6
> |allocation Mb/op|.|.|2441,38858|.|0,002105713|0
> |.|.|.|.|.|.|
> |.|.|secondInMonth/1000|.|.|.|
> |time ms/op|.|.|8988,578|.|5791,179|64,4
> |allocation Mb/op|.|.|2440,951141|.|0,017715454|0
> |.|.|.|.|.|.|
> |.|.|secondInMonth/1|.|.|.|
> |time ms/op|.|.|10711,671|.|5765,243|53,8
> |allocation Mb/op|.|.|2437,022537|.|0,264083862|0
> |.|.|.|.|.|.|
> |.|.|secondInMonth/10|.|.|.|
> |time ms/op|.|.|13001,841|.|5638,069|43,4
> |allocation Mb/op|.|.|2396,947113|.|2,003662109|0,1
> |.|.|.|.|.|.|
> |.|.|secondInDay/0|.|.|.|
> |time ms/op|.|.|10381,833|.|5497,804|53
> |allocation Mb/op|.|.|2441,166107|.|0,002105713|0
> |.|.|.|.|.|.|
> |.|.|secondInDay/1000|.|.|.|
> |time ms/op|.|.|8522,157|.|5929,871|69,6
> |allocation Mb/op|.|.|1973,112381|.|0,017715454|0
> |.|.|.|.|.|.|
> |.|.|secondInDay/1|.|.|.|
> |time ms/op|.|.|10234,978|.|5480,077|53,5
> |allocation Mb/op|.|.|2306,057404|.|0,262969971|0
> |.|.|.|.|.|.|
> |.|.|secondInDay/10|.|.|.|
> |time ms/op|.|.|2971,178|.|139,079|4,7
> |allocation Mb/op|.|.|172,1276245|.|2,001721191|1,2
> |.|.|.|.|.|.|
> |.|.|secondIn3Hour/0|.|.|.|
> |time ms/op|.|.|10663,123|.|5605,672|52,6
> |allocation Mb/op|.|.|2439,456818|.|0,002105713|0
> |.|.|.|.|.|.|
> |.|.|secondIn3Hour/1000|.|.|.|
> |time ms/op|.|.|9029,788|.|5838,618|64,7
> |allocation Mb/op|.|.|2331,839249|.|0,180664063|0
> |.|.|.|.|.|.|
> |.|.|secondIn3Hour/1|.|.|.|
> |time ms/op|.|.|4862,409|.|89,001|1,8
> |allocation Mb/op|.|.|965,4871887|.|0,251711652|0
> |.|.|.|.|.|.|
> |.|.|secondIn3Hour/10|.|.|.|
> |time ms/op|.|.|1484,454|.|95,044|6,4
> |allocation Mb/op|.|.|153,2464722|.|2,001712809|1,3
> |.|.|.|.|.|.|
> |.|.|secondInMin/0|.|.|.|
> |time ms/op|.|.|875,118|.|424,11|48,5
> |allocation Mb/op|.|.|610,3554993|.|0,001776123|0
> |.|.|.|.|.|.|
> |.|.|secondInMin/1000|.|.|.|
> |time ms/op|.|.|568,7|.|84,208|14,8
> |allocation Mb/op|.|.|0,007598114|.|0,01810023|238,2
> |.|.|.|.|.|.|
> |.|.|secondInMin/1|.|.|.|
> |time ms/op|.|.|573,595|.|83,862|14,6
> |allocation

[jira] [Comment Edited] (CASSANDRA-13444) Fast and garbage-free Streaming Histogram

2017-05-16 Thread Jason Brown (JIRA) 

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

Jason Brown edited comment on CASSANDRA-13444 at 5/16/17 11:12 AM:
---

I've taken a first pass reviewing, and this looks really good :). I'm going to 
take another pass or two so I can grok everything, but here are some initial 
comments:

- please add some more documentation to {{StreamingHistogram}}, especially on 
the DistanceHolder, DataHolder, and Spool classes. feel free to expand any of 
the existing comments, as well.
- What if {{Spool#hash}} wraps around? will that cause a problem in 
{{tryAddOrAccumulate}}? admittedly, this is one of the parts I need to read and 
understand more thoroughly.
- In {{Spool#tryAddOrAccumulate}} why loop for a max of 100 iterations? 
- {{DistanceHolder.getFirstAndRemove()}} may return null, which can cause 
{{mergeBin}} to throw an {{NPE}}. what should the correct behavior be here?

While we're improving this class, I don't think it would be much extra work to 
convert {{DataHolder#keySet}} and {{StreamingHistogram#getAsMap}} to return an 
iterator rather than a materialized {{List}} or {{Map}} and avoid all the boxing conversions on that one. 
Are you up for doing that?


was (Author: jasobrown):
I've taken a first pass reviewing, and this looks really good :). I'm going to 
take another pass or two so I can grok everything, but here are some initial 
comments:

- please add some more documentation to {{StreamingHistogram}}, especially on 
the DistanceHolder, DataHolder, and Spool classes. feel free to expand any of 
the existing comments, as well.
- What if {{Spool#hash}} wraps around? will that cause a problem in 
{{tryAddOrAccumulate}}? admittedly, this is one of the parts I need to read and 
understand more thoroughly.
- In {{Spool#tryAddOrAccumulate}} why loop for a max of 100 iterations? 
- {{DistanceHolder.getFirstAndRemove()}} may return null, which can cause 
{{mergeBin}} to throw an {{NPE}}. what should the correct behavior be here?

While we're improving this class, I don't think it would be much extra work to 
convert {[DataHolder#keySet}} and {{StreamingHistogram#getAsMap}} to return an 
iterator rather than a materialized {{List}} or {{Map}} and avoid all the boxing conversions on that one. 
Are you up for doing that?

> Fast and garbage-free Streaming Histogram
> -
>
> Key: CASSANDRA-13444
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13444
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Fuud
>Assignee: Fuud
> Fix For: 4.x
>
> Attachments: results.csv, results.xlsx
>
>
> StreamingHistogram is cause of high cpu usage and GC pressure.
> It was improved at CASSANDRA-13038 by introducing intermediate buffer to try 
> accumulate different values into the big map before merging them into smaller 
> one.
> But there was not enought for TTL's distributed within large time. Rounding 
> (also introduced at 13038) can help but it reduce histogram precision 
> specially in case where TTL's does not distributed uniformly.
> There are several improvements that can help to reduce cpu and gc usage. Them 
> all included in the pool-request as separate revisions thus you can test them 
> independently.
> Improvements list:
> # Use Map.computeIfAbsent instead of get->checkIfNull->put chain. In this way 
> "add-or-accumulate" operation takes one map operation instead of two. But 
> this method (default-defined in interface Map) is overriden in HashMap but 
> not in TreeMap. Thus I changed spool type to HashMap.
> # As we round incoming values to _roundSeconds_ we can also round value on 
> merge. It will enlarge hit rate for bin operations.
> # Because we inserted only integers into Histogram and rounding values to 
> integers we can use *int* type everywhere.
> # Histogram takes huge amount of time merging values. In merge method largest 
> amount of time taken by finding nearest points. It can be eliminated by 
> holding additional TreeSet with differences, sorted from smalest to greatest.
> # Because we know max size of _bin_ and _differences_ maps we can replace 
> them with sorted arrays. Search can be done with _Arrays.binarySearch_ and 
> insertion/deletions can be done by _System.arraycopy_. Also it helps to merge 
> some operations into one.
> # Because spool map is also limited we can replace it with open address 
> primitive map. It's finaly reduce allocation rate to zero.
> You can see gain given by each step in the attached

[jira] [Comment Edited] (CASSANDRA-13444) Fast and garbage-free Streaming Histogram

2017-05-16 Thread Jason Brown (JIRA) 

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

Jason Brown edited comment on CASSANDRA-13444 at 5/16/17 11:12 AM:
---

I've taken a first pass reviewing, and this looks really good :). I'm going to 
take another pass or two so I can grok everything, but here are some initial 
comments:

- please add some more documentation to {{StreamingHistogram}}, especially on 
the DistanceHolder, DataHolder, and Spool classes. feel free to expand any of 
the existing comments, as well.
- What if {{Spool#hash}} wraps around? will that cause a problem in 
{{tryAddOrAccumulate}}? admittedly, this is one of the parts I need to read and 
understand more thoroughly.
- In {{Spool#tryAddOrAccumulate}} why loop for a max of 100 iterations? 
- {{DistanceHolder.getFirstAndRemove()}} may return null, which can cause 
{{mergeBin}} to throw an {{NPE}}. what should the correct behavior be here?

While we're improving this class, I don't think it would be much extra work to 
convert {[DataHolder#keySet}} and {{StreamingHistogram#getAsMap}} to return an 
iterator rather than a materialized {{List}} or {{Map}} and avoid all the boxing conversions on that one. 
Are you up for doing that?


was (Author: jasobrown):
I've taken a first pass reviewing, and this looks really good :). I'm going to 
take another pass or two so I can grok everything, but here are some initial 
comments:

- please add some more documentation to {{StreamingHistogram}}, especially on 
the DistanceHolder, DataHolder, and Spool classes. feel free to expand any of 
the existing comments, as well.
- What if {{Spool#hash}} wraps around? will that cause a problem in 
{{tryAddOrAccumulate}}? admittedly, this is one of the parts is need to read 
and understand more thoroughly.
- In {{Spool#tryAddOrAccumulate}} why loop for a max of 100 iterations? 
- {{DistanceHolder.getFirstAndRemove()}} may return null, which can cause 
{{mergeBin}} to throw an {{NPE}}. what should the correct behavior be here?

While we're improving this class, I don't think it would be much extra work to 
convert {[DataHolder#keySet}} and {{StreamingHistogram#getAsMap}} to return an 
iterator rather than a materialized {{List}} or {{Map}} and avoid all the boxing conversions on that one. 
Are you up for doing that?

> Fast and garbage-free Streaming Histogram
> -
>
> Key: CASSANDRA-13444
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13444
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Fuud
>Assignee: Fuud
> Fix For: 4.x
>
> Attachments: results.csv, results.xlsx
>
>
> StreamingHistogram is cause of high cpu usage and GC pressure.
> It was improved at CASSANDRA-13038 by introducing intermediate buffer to try 
> accumulate different values into the big map before merging them into smaller 
> one.
> But there was not enought for TTL's distributed within large time. Rounding 
> (also introduced at 13038) can help but it reduce histogram precision 
> specially in case where TTL's does not distributed uniformly.
> There are several improvements that can help to reduce cpu and gc usage. Them 
> all included in the pool-request as separate revisions thus you can test them 
> independently.
> Improvements list:
> # Use Map.computeIfAbsent instead of get->checkIfNull->put chain. In this way 
> "add-or-accumulate" operation takes one map operation instead of two. But 
> this method (default-defined in interface Map) is overriden in HashMap but 
> not in TreeMap. Thus I changed spool type to HashMap.
> # As we round incoming values to _roundSeconds_ we can also round value on 
> merge. It will enlarge hit rate for bin operations.
> # Because we inserted only integers into Histogram and rounding values to 
> integers we can use *int* type everywhere.
> # Histogram takes huge amount of time merging values. In merge method largest 
> amount of time taken by finding nearest points. It can be eliminated by 
> holding additional TreeSet with differences, sorted from smalest to greatest.
> # Because we know max size of _bin_ and _differences_ maps we can replace 
> them with sorted arrays. Search can be done with _Arrays.binarySearch_ and 
> insertion/deletions can be done by _System.arraycopy_. Also it helps to merge 
> some operations into one.
> # Because spool map is also limited we can replace it with open address 
> primitive map. It's finaly reduce allocation rate to zero.
> You can see gain given by each step in the attached

[jira] [Commented] (CASSANDRA-13444) Fast and garbage-free Streaming Histogram

2017-05-16 Thread Jason Brown (JIRA) 

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

Jason Brown commented on CASSANDRA-13444:
-

I've taken a first pass reviewing, and this looks really good :). I'm going to 
take another pass or two so I can grok everything, but here are some initial 
comments:

- please add some more documentation to {{StreamingHistogram}}, especially on 
the DistanceHolder, DataHolder, and Spool classes. feel free to expand any of 
the existing comments, as well.
- What if {{Spool#hash}} wraps around? will that cause a problem in 
{{tryAddOrAccumulate}}? admittedly, this is one of the parts is need to read 
and understand more thoroughly.
- In {{Spool#tryAddOrAccumulate}} why loop for a max of 100 iterations? 
- {{DistanceHolder.getFirstAndRemove()}} may return null, which can cause 
{{mergeBin}} to throw an {{NPE}}. what should the correct behavior be here?

While we're improving this class, I don't think it would be much extra work to 
convert {[DataHolder#keySet}} and {{StreamingHistogram#getAsMap}} to return an 
iterator rather than a materialized {{List}} or {{Map}} and avoid all the boxing conversions on that one. 
Are you up for doing that?

> Fast and garbage-free Streaming Histogram
> -
>
> Key: CASSANDRA-13444
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13444
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Fuud
>Assignee: Fuud
> Fix For: 4.x
>
> Attachments: results.csv, results.xlsx
>
>
> StreamingHistogram is cause of high cpu usage and GC pressure.
> It was improved at CASSANDRA-13038 by introducing intermediate buffer to try 
> accumulate different values into the big map before merging them into smaller 
> one.
> But there was not enought for TTL's distributed within large time. Rounding 
> (also introduced at 13038) can help but it reduce histogram precision 
> specially in case where TTL's does not distributed uniformly.
> There are several improvements that can help to reduce cpu and gc usage. Them 
> all included in the pool-request as separate revisions thus you can test them 
> independently.
> Improvements list:
> # Use Map.computeIfAbsent instead of get->checkIfNull->put chain. In this way 
> "add-or-accumulate" operation takes one map operation instead of two. But 
> this method (default-defined in interface Map) is overriden in HashMap but 
> not in TreeMap. Thus I changed spool type to HashMap.
> # As we round incoming values to _roundSeconds_ we can also round value on 
> merge. It will enlarge hit rate for bin operations.
> # Because we inserted only integers into Histogram and rounding values to 
> integers we can use *int* type everywhere.
> # Histogram takes huge amount of time merging values. In merge method largest 
> amount of time taken by finding nearest points. It can be eliminated by 
> holding additional TreeSet with differences, sorted from smalest to greatest.
> # Because we know max size of _bin_ and _differences_ maps we can replace 
> them with sorted arrays. Search can be done with _Arrays.binarySearch_ and 
> insertion/deletions can be done by _System.arraycopy_. Also it helps to merge 
> some operations into one.
> # Because spool map is also limited we can replace it with open address 
> primitive map. It's finaly reduce allocation rate to zero.
> You can see gain given by each step in the attached file. First number is 
> time for one benchmark invocation and second - is allocation rate in Mb per 
> operation.
> Dependends of payload time is reduced up to 90%.
> Overall gain:
> |.|.|Payload/SpoolSize|.|.|.|% from original
> |.|.|.|original|.|optimized|
> |.|.|secondInMonth/0|.|.|.|
> |time ms/op|.|.|10747,684|.|5545,063|51,6
> |allocation Mb/op|.|.|2441,38858|.|0,002105713|0
> |.|.|.|.|.|.|
> |.|.|secondInMonth/1000|.|.|.|
> |time ms/op|.|.|8988,578|.|5791,179|64,4
> |allocation Mb/op|.|.|2440,951141|.|0,017715454|0
> |.|.|.|.|.|.|
> |.|.|secondInMonth/1|.|.|.|
> |time ms/op|.|.|10711,671|.|5765,243|53,8
> |allocation Mb/op|.|.|2437,022537|.|0,264083862|0
> |.|.|.|.|.|.|
> |.|.|secondInMonth/10|.|.|.|
> |time ms/op|.|.|13001,841|.|5638,069|43,4
> |allocation Mb/op|.|.|2396,947113|.|2,003662109|0,1
> |.|.|.|.|.|.|
> |.|.|secondInDay/0|.|.|.|
> |time ms/op|.|.|10381,833|.|5497,804|53
> |allocation Mb/op|.|.|2441,166107|.|0,002105713|0
> |.|.|.|.|.|.|
> |.|.|secondInDay/1000|.|.|.|
> |time ms/op|.|.|8522,157|.|5929,871|69,6
> |allocation Mb/op|.|.|1973,112381|.|0,017715454|0
> |.|.|.|.|.|.|
> |.|.|secondInDay/1|.|.|.|
> |time ms/op|.|.|10234,978|.|5480,077|53,5
> |allocation Mb/op|.|.|2306,057404|.|0,262969971|0

[jira] [Commented] (CASSANDRA-10130) Node failure during 2i update after streaming can have incomplete 2i when restarted

2017-05-16 Thread Sergio Bossa (JIRA) 

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

Sergio Bossa commented on CASSANDRA-10130:
--

Some more feedback by my side too.

I think there still is a subtle concurrency issue, due to the fact we have some 
methods managing the "index status" in the system keyspace via the counter, and 
other methods directly messing with the system keyspace and/or the pending 
builds map; i.e., what happens if the index is unregistered while it is being 
rebuilt? Probably an 
[NPE|https://github.com/apache/cassandra/compare/trunk...adelapena:10130-trunk#diff-3f2c8994c4ff8748c3faf7e70958520dR424].
 I would suggest to clean it up a bit by avoiding to keep "pending builds" in 
the map after they're all done, that is after the index has been marked as 
built: by doing so, you can just remove the pending build inside 
{{markIndexBuilt}} if the counter reaches 0 (you'd have to guard the {{mark*}} 
methods rather than the counter ones), and hence keep the "build management" 
code inside the two "mark building/built" methods only.

I'm kinda unsure if we should actually call {{markIndexBuilding}} inside 
{{createIndex}}: what if the user forgets to call {{markIndexBuilt}} inside the 
initialization task? There's no such contract forcing the user to do that. So, 
as a corollary, we should probably accept calls to {{markIndexBuilt}} even 
without a previous {{markIndexBuilding}} call (that is, making it idempotent).

Also, {{buildAllIndexesBlocking}} doesn't follow the "mark building/built" 
pattern: isn't that a weird anomaly? I know the {{StreamReceiveTask}} does 
that, but what about other callers?

Regarding {{PendingIndexBuildsCounter}}, it isn't really just a counter, I 
would rename it (i.e. just {{PendingBuild}}), and rename its methods as well 
for further clarity; or we could ditch it altogether as suggested by 
[~pauloricardomg].

Finally regarding:

bq. the user will expect the index NOT to be rebuilt on restart if there was a 
subsequent successful rebuild.

Is it what [~adelapena] actually meant? I do not think the index is actually 
rebuilt on restart if successfully rebuilt manually, or am I missing the point?

> Node failure during 2i update after streaming can have incomplete 2i when 
> restarted
> ---
>
> Key: CASSANDRA-10130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10130
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Yuki Morishita
>Assignee: Andrés de la Peña
>Priority: Minor
>
> Since MV/2i update happens after SSTables are received, node failure during 
> MV/2i update can leave received SSTables live when restarted while MV/2i are 
> partially up to date.
> We can add some kind of tracking mechanism to automatically rebuild at the 
> startup, or at least warn user when the node restarts.



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13209) test failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip_blogposts_with_max_connections

2017-05-16 Thread Kurt Greaves (JIRA) 

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

Kurt Greaves edited comment on CASSANDRA-13209 at 5/16/17 8:24 AM:
---

although timeouts do appear in the failures, most of them seem to be occurring 
because the CSV's don't have the expected number of lines. sometimes it's more, 
sometimes less.
A better example is 
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-dtest/134/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip_blogposts_with_max_connections/



seems that the blogposts tests have previously been an issue that wasn't 
resolved https://issues.apache.org/jira/browse/CASSANDRA-10938




was (Author: kurtg):
although timeouts do appear in the failures, most of them seem to be occurring 
because the CSV's don't have the expected number of lines. sometimes it's more, 
sometimes less.
A better example is 
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-dtest/134/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip_blogposts_with_max_connections/



seems that the blogposts tests have previously been an issue. 
https://issues.apache.org/jira/browse/CASSANDRA-10938



> test failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip_blogposts_with_max_connections
> --
>
> Key: CASSANDRA-13209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13209
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Shuler
>Assignee: Kurt Greaves
>  Labels: dtest, test-failure
> Attachments: node1.log, node2.log, node3.log, node4.log, node5.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/528/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip_blogposts_with_max_connections
> {noformat}
> Error Message
> errors={'127.0.0.4': 'Client request timeout. See 
> Session.execute[_async](timeout)'}, last_host=127.0.0.4
>  >> begin captured logging << 
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-792s6j
> dtest: DEBUG: Done setting configuration options:
> {   'initial_token': None,
> 'num_tokens': '32',
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> dtest: DEBUG: removing ccm cluster test at: /tmp/dtest-792s6j
> dtest: DEBUG: clearing ssl stores from [/tmp/dtest-792s6j] directory
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-uNMsuW
> dtest: DEBUG: Done setting configuration options:
> {   'initial_token': None,
> 'num_tokens': '32',
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> cassandra.policies: INFO: Using datacenter 'datacenter1' for 
> DCAwareRoundRobinPolicy (via host '127.0.0.1'); if incorrect, please specify 
> a local_dc to the constructor, or limit contact points to local cluster nodes
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> dtest: DEBUG: Running stress with user profile 
> /home/automaton/cassandra-dtest/cqlsh_tests/blogposts.yaml
> - >> end captured logging << -
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 1090, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2571, in test_bulk_round_trip_blogposts_with_max_connections
> copy_from_options={'NUMPROCESSES': 2})
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2500, in _test_bulk_round_trip
> num_records = create_records()
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2473, in create_records
> ret = rows_to_list(self.session.execute(count_statement))[0][0]
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 1998, in execute
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile, paging_state).result()
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 3784, in result
>

[jira] [Commented] (CASSANDRA-13209) test failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip_blogposts_with_max_connections

2017-05-16 Thread Kurt Greaves (JIRA) 

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

Kurt Greaves commented on CASSANDRA-13209:
--

although timeouts do appear in the failures, most of them seem to be occurring 
because the CSV's don't have the expected number of lines. sometimes it's more, 
sometimes less.
A better example is 
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-dtest/134/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip_blogposts_with_max_connections/



seems that the blogposts tests have previously been an issue. 
https://issues.apache.org/jira/browse/CASSANDRA-10938



> test failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip_blogposts_with_max_connections
> --
>
> Key: CASSANDRA-13209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13209
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Shuler
>Assignee: Kurt Greaves
>  Labels: dtest, test-failure
> Attachments: node1.log, node2.log, node3.log, node4.log, node5.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/528/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip_blogposts_with_max_connections
> {noformat}
> Error Message
> errors={'127.0.0.4': 'Client request timeout. See 
> Session.execute[_async](timeout)'}, last_host=127.0.0.4
>  >> begin captured logging << 
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-792s6j
> dtest: DEBUG: Done setting configuration options:
> {   'initial_token': None,
> 'num_tokens': '32',
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> dtest: DEBUG: removing ccm cluster test at: /tmp/dtest-792s6j
> dtest: DEBUG: clearing ssl stores from [/tmp/dtest-792s6j] directory
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-uNMsuW
> dtest: DEBUG: Done setting configuration options:
> {   'initial_token': None,
> 'num_tokens': '32',
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> cassandra.policies: INFO: Using datacenter 'datacenter1' for 
> DCAwareRoundRobinPolicy (via host '127.0.0.1'); if incorrect, please specify 
> a local_dc to the constructor, or limit contact points to local cluster nodes
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> dtest: DEBUG: Running stress with user profile 
> /home/automaton/cassandra-dtest/cqlsh_tests/blogposts.yaml
> - >> end captured logging << -
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 1090, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2571, in test_bulk_round_trip_blogposts_with_max_connections
> copy_from_options={'NUMPROCESSES': 2})
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2500, in _test_bulk_round_trip
> num_records = create_records()
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2473, in create_records
> ret = rows_to_list(self.session.execute(count_statement))[0][0]
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 1998, in execute
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile, paging_state).result()
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 3784, in result
> raise self._final_exception
> "errors={'127.0.0.4': 'Client request timeout. See 
> Session.execute[_async](timeout)'}, last_host=127.0.0.4\n 
> >> begin captured logging << \ndtest: DEBUG: cluster ccm 
> directory: /tmp/dtest-792s6j\ndtest: DEBUG: Done setting configuration 
> options:\n{   'initial_token': None,\n'num_tokens': '32',\n
> 'phi_convict_threshold': 5,\n'range_request_timeout_in_ms': 1,\n
> 'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n   
>  'truncate_request_timeout_in_ms': 1,\n

[jira] [Commented] (CASSANDRA-13418) Allow TWCS to ignore overlaps when dropping fully expired sstables

2017-05-16 Thread Romain GERARD (JIRA) 

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

Romain GERARD commented on CASSANDRA-13418:
---

Any advices to take a next step forward ?

> Allow TWCS to ignore overlaps when dropping fully expired sstables
> --
>
> Key: CASSANDRA-13418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13418
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Corentin Chary
>  Labels: twcs
>
> http://thelastpickle.com/blog/2016/12/08/TWCS-part1.html explains it well. If 
> you really want read-repairs you're going to have sstables blocking the 
> expiration of other fully expired SSTables because they overlap.
> You can set unchecked_tombstone_compaction = true or tombstone_threshold to a 
> very low value and that will purge the blockers of old data that should 
> already have expired, thus removing the overlaps and allowing the other 
> SSTables to expire.
> The thing is that this is rather CPU intensive and not optimal. If you have 
> time series, you might not care if all your data doesn't exactly expire at 
> the right time, or if data re-appears for some time, as long as it gets 
> deleted as soon as it can. And in this situation I believe it would be really 
> beneficial to allow users to simply ignore overlapping SSTables when looking 
> for fully expired ones.
> To the question: why would you need read-repairs ?
> - Full repairs basically take longer than the TTL of the data on my dataset, 
> so this isn't really effective.
> - Even with a 10% chances of doing a repair, we found out that this would be 
> enough to greatly reduce entropy of the most used data (and if you have 
> timeseries, you're likely to have a dashboard doing the same important 
> queries over and over again).
> - LOCAL_QUORUM is too expensive (need >3 replicas), QUORUM is too slow.
> I'll try to come up with a patch demonstrating how this would work, try it on 
> our system and report the effects.
> cc: [~adejanovski], [~rgerard] as I know you worked on similar issues already.



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13478) SASI Sparse mode overflow corrupts the SSTable

2017-05-16 Thread jack chen (JIRA) 

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

jack chen commented on CASSANDRA-13478:
---

Thank you for your prompt reply, awaits for your good news.

> SASI Sparse mode overflow corrupts the SSTable
> --
>
> Key: CASSANDRA-13478
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13478
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
> Environment: cqlsh 5.0.1 | Cassandra 3.10 | CQL spec 3.4.4 | Native 
> protocol v4 | ubuntu 14.04
>Reporter: jack chen
>Assignee: Alex Petrov
>Priority: Minor
> Attachments: schema
>
>
> I have a table, the schema can be seen in attach file
> I would like to search the data using the timestamp data type with lt gt eq 
> as a query condition,
> Ex:
> {code}
> CREATE TABLE XXX.userlist (
> userid text PRIMARY KEY,
> lastposttime timestamp
> )
> Select * from userlist where lastposttime> '2017-04-01 16:00:00+';
> {code}
> There are 2 conditions :
> If I insert the data and then select it, the result will be correct
> But in case I insert data and then the next day I restart Cassandra, and 
> after that select the data, there will be no data selected
> The difference is that there is no Service restart on th next day in the 
> first manner. Actually, the data are still living in Cassandra, but TimeStamp 
> can’t be used as the query condition



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-13209) test failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip_blogposts_with_max_connections

2017-05-16 Thread Kurt Greaves (JIRA) 

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

Kurt Greaves reassigned CASSANDRA-13209:


Assignee: Kurt Greaves

> test failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip_blogposts_with_max_connections
> --
>
> Key: CASSANDRA-13209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13209
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Shuler
>Assignee: Kurt Greaves
>  Labels: dtest, test-failure
> Attachments: node1.log, node2.log, node3.log, node4.log, node5.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/528/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip_blogposts_with_max_connections
> {noformat}
> Error Message
> errors={'127.0.0.4': 'Client request timeout. See 
> Session.execute[_async](timeout)'}, last_host=127.0.0.4
>  >> begin captured logging << 
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-792s6j
> dtest: DEBUG: Done setting configuration options:
> {   'initial_token': None,
> 'num_tokens': '32',
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> dtest: DEBUG: removing ccm cluster test at: /tmp/dtest-792s6j
> dtest: DEBUG: clearing ssl stores from [/tmp/dtest-792s6j] directory
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-uNMsuW
> dtest: DEBUG: Done setting configuration options:
> {   'initial_token': None,
> 'num_tokens': '32',
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> cassandra.policies: INFO: Using datacenter 'datacenter1' for 
> DCAwareRoundRobinPolicy (via host '127.0.0.1'); if incorrect, please specify 
> a local_dc to the constructor, or limit contact points to local cluster nodes
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> cassandra.cluster: INFO: New Cassandra host  
> discovered
> dtest: DEBUG: Running stress with user profile 
> /home/automaton/cassandra-dtest/cqlsh_tests/blogposts.yaml
> - >> end captured logging << -
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 1090, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2571, in test_bulk_round_trip_blogposts_with_max_connections
> copy_from_options={'NUMPROCESSES': 2})
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2500, in _test_bulk_round_trip
> num_records = create_records()
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2473, in create_records
> ret = rows_to_list(self.session.execute(count_statement))[0][0]
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 1998, in execute
> return self.execute_async(query, parameters, trace, custom_payload, 
> timeout, execution_profile, paging_state).result()
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 3784, in result
> raise self._final_exception
> "errors={'127.0.0.4': 'Client request timeout. See 
> Session.execute[_async](timeout)'}, last_host=127.0.0.4\n 
> >> begin captured logging << \ndtest: DEBUG: cluster ccm 
> directory: /tmp/dtest-792s6j\ndtest: DEBUG: Done setting configuration 
> options:\n{   'initial_token': None,\n'num_tokens': '32',\n
> 'phi_convict_threshold': 5,\n'range_request_timeout_in_ms': 1,\n
> 'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n   
>  'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms': 
> 1}\ndtest: DEBUG: removing ccm cluster test at: /tmp/dtest-792s6j\ndtest: 
> DEBUG: clearing ssl stores from [/tmp/dtest-792s6j] directory\ndtest: DEBUG: 
> cluster ccm directory: /tmp/dtest-uNMsuW\ndtest: DEBUG: Done setting 
> configuration options:\n{   'initial_token': None,\n'num_tokens': '32',\n 
>'phi_convict_threshold': 5,\n'range_request_timeout_in_ms': 1,\n   
>  'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n  
>

[jira] [Assigned] (CASSANDRA-13102) test failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip_blogposts

2017-05-16 Thread Kurt Greaves (JIRA) 

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

Kurt Greaves reassigned CASSANDRA-13102:


Assignee: Kurt Greaves

> test failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip_blogposts
> -
>
> Key: CASSANDRA-13102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13102
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Shuler
>Assignee: Kurt Greaves
>  Labels: dtest, test-failure
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/875/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip_blogposts
> {noformat}
> Error Message
> ('Unable to connect to any servers', {'127.0.0.1': error(111, "Tried 
> connecting to [('127.0.0.1', 9042)]. Last error: Connection refused")})
>  >> begin captured logging << 
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-1c8hQM
> dtest: DEBUG: Done setting configuration options:
> {   'initial_token': None,
> 'num_tokens': '32',
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> dtest: DEBUG: removing ccm cluster test at: /tmp/dtest-1c8hQM
> dtest: DEBUG: clearing ssl stores from [/tmp/dtest-1c8hQM] directory
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-C2OXmx
> dtest: DEBUG: Done setting configuration options:
> {   'initial_token': None,
> 'num_tokens': '32',
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> - >> end captured logging << -
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 1079, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2553, in test_bulk_round_trip_blogposts
> stress_table='stresscql.blogposts')
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2456, in _test_bulk_round_trip
> self.prepare(nodes=nodes, partitioner=partitioner, 
> configuration_options=configuration_options)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 129, in prepare
> self.session = self.patient_cql_connection(self.node1)
>   File "/home/automaton/cassandra-dtest/dtest.py", line 508, in 
> patient_cql_connection
> bypassed_exception=NoHostAvailable
>   File "/home/automaton/cassandra-dtest/dtest.py", line 201, in 
> retry_till_success
> return fun(*args, **kwargs)
>   File "/home/automaton/cassandra-dtest/dtest.py", line 441, in cql_connection
> protocol_version, port=port, ssl_opts=ssl_opts)
>   File "/home/automaton/cassandra-dtest/dtest.py", line 469, in 
> _create_session
> session = cluster.connect(wait_for_all_pools=True)
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 1180, in connect
> self.control_connection.connect()
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 2597, in connect
> self._set_new_connection(self._reconnect_internal())
>   File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line 
> 2634, in _reconnect_internal
> raise NoHostAvailable("Unable to connect to any servers", errors)
> '(\'Unable to connect to any servers\', {\'127.0.0.1\': error(111, "Tried 
> connecting to [(\'127.0.0.1\', 9042)]. Last error: Connection 
> refused")})\n >> begin captured logging << 
> \ndtest: DEBUG: cluster ccm directory: 
> /tmp/dtest-1c8hQM\ndtest: DEBUG: Done setting configuration options:\n{   
> \'initial_token\': None,\n\'num_tokens\': \'32\',\n
> \'phi_convict_threshold\': 5,\n\'range_request_timeout_in_ms\': 1,\n  
>   \'read_request_timeout_in_ms\': 1,\n\'request_timeout_in_ms\': 
> 1,\n\'truncate_request_timeout_in_ms\': 1,\n
> \'write_request_timeout_in_ms\': 1}\ndtest: DEBUG: removing ccm cluster 
> test at: /tmp/dtest-1c8hQM\ndtest: DEBUG: clearing ssl stores from 
> [/tmp/dtest-1c8hQM] directory\ndtest: DEBUG: cluster ccm directory: 
> /tmp/dtest-C2OXmx\ndtest: DEBUG: Done setting configuration options:\n{   
> \'initial_token\': None,\n\'num_tokens\': \'32\',\n
> \'phi_convict_threshold\': 5,\n\'range_request_timeout_in_ms\': 1,\n  
>

[jira] [Updated] (CASSANDRA-13142) Upgradesstables cancels compactions unnecessarily

2017-05-16 Thread Marcus Eriksson (JIRA) 

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

Marcus Eriksson updated CASSANDRA-13142:

Reviewer: Marcus Eriksson

> Upgradesstables cancels compactions unnecessarily
> -
>
> Key: CASSANDRA-13142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13142
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
> Attachments: 13142-v1.patch
>
>
> Since at least 1.2 upgradesstables will cancel any compactions bar 
> validations when run. This was originally determined as a non-issue in 
> CASSANDRA-3430 however can be quite annoying (especially with STCS) as a 
> compaction will output the new version anyway. Furthermore, as per 
> CASSANDRA-12243 it also stops things like view builds and I assume secondary 
> index builds as well which is not ideal.
> We should avoid cancelling compactions unnecessarily.



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13142) Upgradesstables cancels compactions unnecessarily

2017-05-16 Thread Marcus Eriksson (JIRA) 

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

Marcus Eriksson commented on CASSANDRA-13142:
-

this idea makes sense to me, a few comments;
* We should probably interrupt all compactions if the user runs 
"upgradesstables -a"
* Maybe we should block until the running compactions are finished? An operator 
might expect all sstables to be upgraded after running upgradesstables but that 
might not be true after this patch. We would probably need to keep track of the 
compaction-futures and get a 'snapshot' of the interesting ones (for the 
current table) when upgradesstables start, and then, when upgradesstables is 
finished, we wait for the futures in the snapshot to finish.
* 
[this|https://github.com/instaclustr/cassandra/blob/18570092324f6ab6bace9d3ce3673f59e7d10d7b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2872-L2878]
 will always return null if we don't cancel the ongoing compactions 
({{getCompacting()}} will not be empty) - I guess we need to compare with which 
compactions we expect to be cancelled?
* {{cfs.markAllCompacting()}} will fail if we don't actually cancel all ongoing 
compactions
* 
[this|https://github.com/instaclustr/cassandra/blob/18570092324f6ab6bace9d3ce3673f59e7d10d7b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2900-L2907]
 looks like it will only cancel validation compaction (if that parameter is 
set), nothing else.
* 
[this|https://github.com/instaclustr/cassandra/blob/18570092324f6ab6bace9d3ce3673f59e7d10d7b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L1748-L1754]
 will also only ever cancel validation compaction (ie, it calls 
{{interruptCompactionFor}} with an empty list)
* 
[this|https://github.com/instaclustr/cassandra/blob/18570092324f6ab6bace9d3ce3673f59e7d10d7b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L1751]
 creates a new list and calls {{.add}} on it - this returns {{true}}, not the 
new list, so it will recurse forever


> Upgradesstables cancels compactions unnecessarily
> -
>
> Key: CASSANDRA-13142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13142
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
> Attachments: 13142-v1.patch
>
>
> Since at least 1.2 upgradesstables will cancel any compactions bar 
> validations when run. This was originally determined as a non-issue in 
> CASSANDRA-3430 however can be quite annoying (especially with STCS) as a 
> compaction will output the new version anyway. Furthermore, as per 
> CASSANDRA-12243 it also stops things like view builds and I assume secondary 
> index builds as well which is not ideal.
> We should avoid cancelling compactions unnecessarily.



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13478) SASI Sparse mode overflow corrupts the SSTable

2017-05-16 Thread Alex Petrov (JIRA) 

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

Alex Petrov commented on CASSANDRA-13478:
-

Currently, SPARSE mode would throw an exception if there're more than 5 items 
per term in the sstable. This results into the not being able to query the 
index and therefore not returning any results.

I'd argue that even though sparse mode is made for the cases when there are 
just a few tokens per sstable, we have to allow any amount. This will result 
into worse performance (because of the token tree reads) but there might be 
cases when giving a hard guarantee on 5 isn't possible to achieve (any user 
generated data). I'd say we have to change the current behaviour and test it 
well.

> SASI Sparse mode overflow corrupts the SSTable
> --
>
> Key: CASSANDRA-13478
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13478
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
> Environment: cqlsh 5.0.1 | Cassandra 3.10 | CQL spec 3.4.4 | Native 
> protocol v4 | ubuntu 14.04
>Reporter: jack chen
>Assignee: Alex Petrov
>Priority: Minor
> Attachments: schema
>
>
> I have a table, the schema can be seen in attach file
> I would like to search the data using the timestamp data type with lt gt eq 
> as a query condition,
> Ex:
> {code}
> CREATE TABLE XXX.userlist (
> userid text PRIMARY KEY,
> lastposttime timestamp
> )
> Select * from userlist where lastposttime> '2017-04-01 16:00:00+';
> {code}
> There are 2 conditions :
> If I insert the data and then select it, the result will be correct
> But in case I insert data and then the next day I restart Cassandra, and 
> after that select the data, there will be no data selected
> The difference is that there is no Service restart on th next day in the 
> first manner. Actually, the data are still living in Cassandra, but TimeStamp 
> can’t be used as the query condition



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-13478) SASIndex has a time to live issue in Cassandra

2017-05-16 Thread Alex Petrov (JIRA) 

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

Alex Petrov reassigned CASSANDRA-13478:
---

Assignee: Alex Petrov

> SASIndex has a time to live issue in Cassandra
> --
>
> Key: CASSANDRA-13478
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13478
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
> Environment: cqlsh 5.0.1 | Cassandra 3.10 | CQL spec 3.4.4 | Native 
> protocol v4 | ubuntu 14.04
>Reporter: jack chen
>Assignee: Alex Petrov
>Priority: Minor
> Attachments: schema
>
>
> I have a table, the schema can be seen in attach file
> I would like to search the data using the timestamp data type with lt gt eq 
> as a query condition,
> Ex:
> {code}
> CREATE TABLE XXX.userlist (
> userid text PRIMARY KEY,
> lastposttime timestamp
> )
> Select * from userlist where lastposttime> '2017-04-01 16:00:00+';
> {code}
> There are 2 conditions :
> If I insert the data and then select it, the result will be correct
> But in case I insert data and then the next day I restart Cassandra, and 
> after that select the data, there will be no data selected
> The difference is that there is no Service restart on th next day in the 
> first manner. Actually, the data are still living in Cassandra, but TimeStamp 
> can’t be used as the query condition



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13478) SASI Sparse mode overflow corrupts the SSTable

2017-05-16 Thread Alex Petrov (JIRA) 

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

Alex Petrov updated CASSANDRA-13478:

Summary: SASI Sparse mode overflow corrupts the SSTable  (was: SASIndex has 
a time to live issue in Cassandra)

> SASI Sparse mode overflow corrupts the SSTable
> --
>
> Key: CASSANDRA-13478
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13478
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
> Environment: cqlsh 5.0.1 | Cassandra 3.10 | CQL spec 3.4.4 | Native 
> protocol v4 | ubuntu 14.04
>Reporter: jack chen
>Assignee: Alex Petrov
>Priority: Minor
> Attachments: schema
>
>
> I have a table, the schema can be seen in attach file
> I would like to search the data using the timestamp data type with lt gt eq 
> as a query condition,
> Ex:
> {code}
> CREATE TABLE XXX.userlist (
> userid text PRIMARY KEY,
> lastposttime timestamp
> )
> Select * from userlist where lastposttime> '2017-04-01 16:00:00+';
> {code}
> There are 2 conditions :
> If I insert the data and then select it, the result will be correct
> But in case I insert data and then the next day I restart Cassandra, and 
> after that select the data, there will be no data selected
> The difference is that there is no Service restart on th next day in the 
> first manner. Actually, the data are still living in Cassandra, but TimeStamp 
> can’t be used as the query condition



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

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org