[jira] [Comment Edited] (CASSANDRA-8274) Node fails to rejoin cluster on EC2 if private IP is changed

[Chris mildebrandt (JIRA)]

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

Chris mildebrandt edited comment on CASSANDRA-8274 at 9/23/17 4:39 AM:
---

I just hit this issue today with the 3.11.0 docker image running in kubernetes. 
I had 4 nodes in the cassandra cluster, two members were restarted (and their 
IPs changed) and can't rejoin. There's one seed that is up and reachable from 
all the other containers, and one other member that is able to join. The first 
exception I see is this:

{noformat}
java.lang.RuntimeException: Cache schema version 
38e97a53-563b-3074-b86f-c81efa980524 does not match current schema version 
1bfdabae-743e-357e-a661-93984c26bc32
at 
org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:206) 
~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.cache.AutoSavingCache$3.call(AutoSavingCache.java:164) 
[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.cache.AutoSavingCache$3.call(AutoSavingCache.java:160) 
[apache-cassandra-3.11.0.jar:3.11.0]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
[na:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_131]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131]
{noformat}


Then I see the one related to this issue:

{noformat}
java.lang.RuntimeException: Unable to gossip with any seeds
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1413) 
~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:550)
 ~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:801)
 ~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:666) 
~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:612) 
~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:393) 
[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600) 
[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689) 
[apache-cassandra-3.11.0.jar:3.11.0]
{noformat}


Restarting the nodes didn't help. nodetool status is now reporting only two 
nodes, and nodetool gossipinfo has three "empty" entries:


{noformat}
/100.96.3.164
  generation:0
  heartbeat:0
  TOKENS: not present
/100.96.1.7
  generation:0
  heartbeat:0
  TOKENS: not present
/100.96.2.170
  generation:0
  heartbeat:0
  TOKENS: not present
{noformat}




was (Author: mildebrandt):
I just hit this issue today with the 3.11.0 docker image running in kubernetes. 
I had 4 nodes in the cassandra cluster, two members were restarted and can't 
rejoin. There's one seed that is up and reachable from all the other 
containers, and one other member that is able to join. The first exception I 
see is this:
{{java.lang.RuntimeException: Cache schema version 
38e97a53-563b-3074-b86f-c81efa980524 does not match current schema version 
1bfdabae-743e-357e-a661-93984c26bc32
at 
org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:206) 
~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.cache.AutoSavingCache$3.call(AutoSavingCache.java:164) 
[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.cache.AutoSavingCache$3.call(AutoSavingCache.java:160) 
[apache-cassandra-3.11.0.jar:3.11.0]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
[na:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_131]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131]}}

Then I see the one related to this issue:
{{java.lang.RuntimeException: Unable to gossip with any seeds
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1413) 
~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:550)
 ~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:801)
 ~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:666) 

[jira] [Commented] (CASSANDRA-8274) Node fails to rejoin cluster on EC2 if private IP is changed

[Chris mildebrandt (JIRA)]

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

Chris mildebrandt commented on CASSANDRA-8274:
--

I just hit this issue today with the 3.11.0 docker image running in kubernetes. 
I had 4 nodes in the cassandra cluster, two members were restarted and can't 
rejoin. There's one seed that is up and reachable from all the other 
containers, and one other member that is able to join. The first exception I 
see is this:
{{java.lang.RuntimeException: Cache schema version 
38e97a53-563b-3074-b86f-c81efa980524 does not match current schema version 
1bfdabae-743e-357e-a661-93984c26bc32
at 
org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:206) 
~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.cache.AutoSavingCache$3.call(AutoSavingCache.java:164) 
[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.cache.AutoSavingCache$3.call(AutoSavingCache.java:160) 
[apache-cassandra-3.11.0.jar:3.11.0]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
[na:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_131]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131]}}

Then I see the one related to this issue:
{{java.lang.RuntimeException: Unable to gossip with any seeds
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1413) 
~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:550)
 ~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:801)
 ~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:666) 
~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:612) 
~[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:393) 
[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600) 
[apache-cassandra-3.11.0.jar:3.11.0]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689) 
[apache-cassandra-3.11.0.jar:3.11.0]}}

Restarting the nodes didn't help. nodetool status is now reporting only two 
nodes, and nodetool gossipinfo has three "empty" entries:

{{/100.96.3.164
  generation:0
  heartbeat:0
  TOKENS: not present
/100.96.1.7
  generation:0
  heartbeat:0
  TOKENS: not present
/100.96.2.170
  generation:0
  heartbeat:0
  TOKENS: not present}}


> Node fails to rejoin cluster on EC2 if private IP is changed
> 
>
> Key: CASSANDRA-8274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8274
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
> Environment: Amazon EC2
>Reporter: Joseph Clark
>Priority: Minor
> Fix For: 3.11.x
>
>
> Nodes in Amazon AWS EC2 Classic (not a VPC) may be assigned a new private IP 
> if the node is stopped and then started again. In this case we have puppet 
> update the configured listen_address to the new private IP. However, once the 
> cassandra service starts, it is unable to communicate with the existing 
> nodes(single region) and vice versa.
> 'nodetool status' shows that each node believes that it is 'UN' and the other 
> node is 'DN'.
> 'nodetool gossipinfo' on the node that remained running shows the *old* 
> private IP listed as the 'INTERNAL_IP' of the node that was stopped and 
> restarted. 
> The situation is resolved by restarting the cassandra service on the node 
> that remained running. Once it has restarted, the INTERNAL_IP is correctly 
> updated to the new private IP. 'nodetool status' shows that both nodes are up 
> and the cluster appears to function normally.
> This appears to me to be the root cause of 
> https://issues.apache.org/jira/browse/CASSANDRA-7292. -Possibly 
> https://issues.apache.org/jira/browse/CASSANDRA-8072 as well, but I am not 
> convinced they are actually duplicates.-



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (CASSANDRA-13890) Expose current compaction throughput

[Jon Haddad (JIRA)]

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

Jon Haddad reassigned CASSANDRA-13890:
--

Assignee: Jon Haddad

> Expose current compaction throughput
> 
>
> Key: CASSANDRA-13890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13890
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Minor
>  Labels: lhf
> Fix For: 4.0
>
>
> Getting and setting the current compaction throughput limit is supported, but 
> there's no means of knowing if the setting is actually making a difference.
> Let's expose the current throughput being utilized by Cassandra that's in the 
> {{compactionRateLimiter}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13896) Improving Cassandra write performance

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13896:


Those numbers look really odd. Can you also post your stress profile and the 
server's yaml? 


> Improving Cassandra write performance  
> ---
>
> Key: CASSANDRA-13896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13896
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
> Environment: Skylake server with 2 sockets, 192GB RAM, 3xPCIe SSDs
> OS: Centos 7.3 
> Java: Oracle JDK1.8.0_121
>Reporter: Prince Nana Owusu Boateng
>  Labels: Performance
> Fix For: 4.x
>
> Attachments: Screen Shot 2017-09-22 at 11.22.43 AM.png, Screen Shot 
> 2017-09-22 at 3.31.09 PM.png
>
>
> During our Cassandra performance testing, we see high percentage of the CPU 
> spent in *org.apache.cassandra.utils.memory.SlabAllocator.allocate(int, 
> OpOrder Group) * method.  Appears to be high contention of the 
> ** atomic Integer in write workloads.   This structure is 
> used by the threads for keeping track of the region bytebuffer allocation.  
> When the contention appears, adding more clients, modifications of write 
> specific parameters does not change write throughput performance.  Attached 
> are the details of Java Flight Recorder (JFR), showing hot functions and also 
> performance results.   When we see this contention, we still have plenty of 
> CPU and throughput left ( *<20%*  Total average CPU utilization and  *<11%* 
> of the storage write total throughput).   This occurs on Cassandra 3.10.0-src 
> version using the Cassandra-Stress.
> Proposal:
> We will like to introduce a solution which eliminates the atomic operations 
> on the ** atomic Integer. This implementation will allow 
> concurrent allocation of bytebuffers without an atomic compareAndSet and 
> incrementAndGet operations. The solution is expected to increase overall 
> write performance while improving CPU utilization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13896) Improving Cassandra write performance

[Prince Nana Owusu Boateng (JIRA)]

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

Prince Nana Owusu Boateng updated CASSANDRA-13896:
--
 Attachment: Screen Shot 2017-09-22 at 3.31.09 PM.png
Description: 
During our Cassandra performance testing, we see high percentage of the CPU 
spent in *org.apache.cassandra.utils.memory.SlabAllocator.allocate(int, OpOrder 
Group) * method.  Appears to be high contention of the ** 
atomic Integer in write workloads.   This structure is used by the threads for 
keeping track of the region bytebuffer allocation.  When the contention 
appears, adding more clients, modifications of write specific parameters does 
not change write throughput performance.  Attached are the details of Java 
Flight Recorder (JFR), showing hot functions and also performance results.   
When we see this contention, we still have plenty of CPU and throughput left ( 
*<20%*  Total average CPU utilization and  *<11%* of the storage write total 
throughput).   This occurs on Cassandra 3.10.0-src version using the 
Cassandra-Stress.

Proposal:
We will like to introduce a solution which eliminates the atomic operations on 
the ** atomic Integer. This implementation will allow 
concurrent allocation of bytebuffers without an atomic compareAndSet and 
incrementAndGet operations. The solution is expected to increase overall write 
performance while improving CPU utilization.

  was:
During our Cassandra performance testing, we see high percentage of the CPU 
spent in *org.apache.cassandra.utils.memory.SlabAllocator.allocate(int, OpOrder 
Group) * method.  Appears to be high contention of the ** 
atomic Integer in write workloads.   This structure is used by the threads for 
keeping track of the region bytebuffer allocation.  When the contention 
appears, adding more clients, modifications of write specific parameters does 
not change write throughput performance.  Attached are the details of Java 
Flight Recorder (JFR), showing hot functions.   When we see this contention, we 
still have plenty of CPU and throughput left ( *<20%*  Total average CPU 
utilization and * <11%* of the storage write total throughput).   This occurs 
on Cassandra 3.10.0-src version using the Cassandra-Stress.

Proposal:
We will like to introduce a solution which eliminates the atomic operations on 
the ** atomic Integer. This implementation will allow 
concurrent allocation of bytebuffers without an atomic compareAndSet and 
incrementAndGet operations. The solution is expected to increase overall write 
performance while improving CPU utilization.


I'm working on having a patch for this soon.

*+Throughput:+*
Results:
Op rate   :   18,233 op/s  [insert: 18,233 op/s]
Partition rate:   18,233 pk/s  [insert: 18,233 pk/s]
Row rate  :  182,364 row/s [insert: 182,364 row/s]
Latency mean  :6.8 ms [insert: 6.8 ms]
Latency median:4.4 ms [insert: 4.4 ms]
Latency 95th percentile   :   19.4 ms [insert: 19.4 ms]
Latency 99th percentile   :   25.9 ms [insert: 25.9 ms]
Latency 99.9th percentile :   85.3 ms [insert: 85.3 ms]
Latency max   :  376.2 ms [insert: 376.2 ms]
Total partitions  : 32,823,392 [insert: 32,823,392]
Total errors  :  0 [insert: 0]
Total GC count: 0
Total GC memory   : 0.000 KiB
Total GC time :0.0 seconds
Avg GC time   :NaN ms
StdDev GC time:0.0 ms
Total operation time  : 00:30:00

> Improving Cassandra write performance  
> ---
>
> Key: CASSANDRA-13896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13896
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
> Environment: Skylake server with 2 sockets, 192GB RAM, 3xPCIe SSDs
> OS: Centos 7.3 
> Java: Oracle JDK1.8.0_121
>Reporter: Prince Nana Owusu Boateng
>  Labels: Performance
> Fix For: 4.x
>
> Attachments: Screen Shot 2017-09-22 at 11.22.43 AM.png, Screen Shot 
> 2017-09-22 at 3.31.09 PM.png
>
>
> During our Cassandra performance testing, we see high percentage of the CPU 
> spent in *org.apache.cassandra.utils.memory.SlabAllocator.allocate(int, 
> OpOrder Group) * method.  Appears to be high contention of the 
> ** atomic Integer in write workloads.   This structure is 
> used by the threads for keeping track of the region bytebuffer allocation.  
> When the contention appears, adding more clients, modifications of write 
> specific parameters does not change write throughput performance.  Attached 
> are the details of Java Flight Recorder (JFR), showing hot functions and also 
> performance results.   When we see this contention, we still have plenty of 
> CPU and throughput left ( *<20%*  

[jira] [Commented] (CASSANDRA-12961) LCS needlessly checks for L0 STCS candidates multiple times

[Vusal Ahmadoglu (JIRA)]

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

Vusal Ahmadoglu commented on CASSANDRA-12961:
-

Okay. Thanks, Jeff!

> LCS needlessly checks for L0 STCS candidates multiple times
> ---
>
> Key: CASSANDRA-12961
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12961
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Jeff Jirsa
>Assignee: Vusal Ahmadoglu
>Priority: Trivial
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 
> 0001-CASSANDRA-12961-Moving-getSTCSInL0CompactionCandidat.patch
>
>
> It's very likely that the check for L0 STCS candidates (if L0 is falling 
> behind) can be moved outside of the loop, or at very least made so that it's 
> not called on each loop iteration:
> {code}
> for (int i = generations.length - 1; i > 0; i--)
> {
> List sstables = getLevel(i);
> if (sstables.isEmpty())
> continue; // mostly this just avoids polluting the debug log 
> with zero scores
> // we want to calculate score excluding compacting ones
> Set sstablesInLevel = Sets.newHashSet(sstables);
> Set remaining = Sets.difference(sstablesInLevel, 
> cfs.getTracker().getCompacting());
> double score = (double) SSTableReader.getTotalBytes(remaining) / 
> (double)maxBytesForLevel(i, maxSSTableSizeInBytes);
> logger.trace("Compaction score for level {} is {}", i, score);
> if (score > 1.001)
> {
> // before proceeding with a higher level, let's see if L0 is 
> far enough behind to warrant STCS
> CompactionCandidate l0Compaction = 
> getSTCSInL0CompactionCandidate();
> if (l0Compaction != null)
> return l0Compaction;
> ..
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13896) Improving Cassandra write performance

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13896:
---
Labels: Performance  (was: )

> Improving Cassandra write performance  
> ---
>
> Key: CASSANDRA-13896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13896
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
> Environment: Skylake server with 2 sockets, 192GB RAM, 3xPCIe SSDs
> OS: Centos 7.3 
> Java: Oracle JDK1.8.0_121
>Reporter: Prince Nana Owusu Boateng
>  Labels: Performance
> Fix For: 4.x
>
> Attachments: Screen Shot 2017-09-22 at 11.22.43 AM.png
>
>
> During our Cassandra performance testing, we see high percentage of the CPU 
> spent in *org.apache.cassandra.utils.memory.SlabAllocator.allocate(int, 
> OpOrder Group) * method.  Appears to be high contention of the 
> ** atomic Integer in write workloads.   This structure is 
> used by the threads for keeping track of the region bytebuffer allocation.  
> When the contention appears, adding more clients, modifications of write 
> specific parameters does not change write throughput performance.  Attached 
> are the details of Java Flight Recorder (JFR), showing hot functions.   When 
> we see this contention, we still have plenty of CPU and throughput left ( 
> *<20%*  Total average CPU utilization and * <11%* of the storage write total 
> throughput).   This occurs on Cassandra 3.10.0-src version using the 
> Cassandra-Stress.
> Proposal:
> We will like to introduce a solution which eliminates the atomic operations 
> on the ** atomic Integer. This implementation will allow 
> concurrent allocation of bytebuffers without an atomic compareAndSet and 
> incrementAndGet operations. The solution is expected to increase overall 
> write performance while improving CPU utilization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13896) Improving Cassandra write performance

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13896:


Another vote for having it in 4.x (trunk) only. [~PrinceNana] - it'd be 
*+great+* to see such an improvement, but please do target the trunk branch, 
and not cassandra-3.11 or cassandra-3.0



> Improving Cassandra write performance  
> ---
>
> Key: CASSANDRA-13896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13896
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
> Environment: Skylake server with 2 sockets, 192GB RAM, 3xPCIe SSDs
> OS: Centos 7.3 
> Java: Oracle JDK1.8.0_121
>Reporter: Prince Nana Owusu Boateng
> Fix For: 4.x
>
> Attachments: Screen Shot 2017-09-22 at 11.22.43 AM.png
>
>
> During our Cassandra performance testing, we see high percentage of the CPU 
> spent in *org.apache.cassandra.utils.memory.SlabAllocator.allocate(int, 
> OpOrder Group) * method.  Appears to be high contention of the 
> ** atomic Integer in write workloads.   This structure is 
> used by the threads for keeping track of the region bytebuffer allocation.  
> When the contention appears, adding more clients, modifications of write 
> specific parameters does not change write throughput performance.  Attached 
> are the details of Java Flight Recorder (JFR), showing hot functions.   When 
> we see this contention, we still have plenty of CPU and throughput left ( 
> *<20%*  Total average CPU utilization and * <11%* of the storage write total 
> throughput).   This occurs on Cassandra 3.10.0-src version using the 
> Cassandra-Stress.
> Proposal:
> We will like to introduce a solution which eliminates the atomic operations 
> on the ** atomic Integer. This implementation will allow 
> concurrent allocation of bytebuffers without an atomic compareAndSet and 
> incrementAndGet operations. The solution is expected to increase overall 
> write performance while improving CPU utilization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13896) Improving Cassandra write performance

[Michael Shuler (JIRA)]

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

Michael Shuler edited comment on CASSANDRA-13896 at 9/22/17 8:34 PM:
-

I set to 4.x fix version, since this is the appropriate version for new 
features and improvements. It's possible this change is minor enough to go into 
3.11.x, but I'll leave that up to the developers. Thanks!


was (Author: mshuler):
I set to 4.x fix version, since this is the appropriate version new features 
and improvements. It's possible this change is minor enough to go into 3.11.x, 
but I'll leave that up to the developers. Thanks!

> Improving Cassandra write performance  
> ---
>
> Key: CASSANDRA-13896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13896
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
> Environment: Skylake server with 2 sockets, 192GB RAM, 3xPCIe SSDs
> OS: Centos 7.3 
> Java: Oracle JDK1.8.0_121
>Reporter: Prince Nana Owusu Boateng
> Fix For: 4.x
>
> Attachments: Screen Shot 2017-09-22 at 11.22.43 AM.png
>
>
> During our Cassandra performance testing, we see high percentage of the CPU 
> spent in *org.apache.cassandra.utils.memory.SlabAllocator.allocate(int, 
> OpOrder Group) * method.  Appears to be high contention of the 
> ** atomic Integer in write workloads.   This structure is 
> used by the threads for keeping track of the region bytebuffer allocation.  
> When the contention appears, adding more clients, modifications of write 
> specific parameters does not change write throughput performance.  Attached 
> are the details of Java Flight Recorder (JFR), showing hot functions.   When 
> we see this contention, we still have plenty of CPU and throughput left ( 
> *<20%*  Total average CPU utilization and * <11%* of the storage write total 
> throughput).   This occurs on Cassandra 3.10.0-src version using the 
> Cassandra-Stress.
> Proposal:
> We will like to introduce a solution which eliminates the atomic operations 
> on the ** atomic Integer. This implementation will allow 
> concurrent allocation of bytebuffers without an atomic compareAndSet and 
> incrementAndGet operations. The solution is expected to increase overall 
> write performance while improving CPU utilization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13896) Improving Cassandra write performance

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-13896:


I set to 4.x fix version, since this is the appropriate version new features 
and improvements. It's possible this change is minor enough to go into 3.11.x, 
but I'll leave that up to the developers. Thanks!

> Improving Cassandra write performance  
> ---
>
> Key: CASSANDRA-13896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13896
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
> Environment: Skylake server with 2 sockets, 192GB RAM, 3xPCIe SSDs
> OS: Centos 7.3 
> Java: Oracle JDK1.8.0_121
>Reporter: Prince Nana Owusu Boateng
> Fix For: 4.x
>
> Attachments: Screen Shot 2017-09-22 at 11.22.43 AM.png
>
>
> During our Cassandra performance testing, we see high percentage of the CPU 
> spent in *org.apache.cassandra.utils.memory.SlabAllocator.allocate(int, 
> OpOrder Group) * method.  Appears to be high contention of the 
> ** atomic Integer in write workloads.   This structure is 
> used by the threads for keeping track of the region bytebuffer allocation.  
> When the contention appears, adding more clients, modifications of write 
> specific parameters does not change write throughput performance.  Attached 
> are the details of Java Flight Recorder (JFR), showing hot functions.   When 
> we see this contention, we still have plenty of CPU and throughput left ( 
> *<20%*  Total average CPU utilization and * <11%* of the storage write total 
> throughput).   This occurs on Cassandra 3.10.0-src version using the 
> Cassandra-Stress.
> Proposal:
> We will like to introduce a solution which eliminates the atomic operations 
> on the ** atomic Integer. This implementation will allow 
> concurrent allocation of bytebuffers without an atomic compareAndSet and 
> incrementAndGet operations. The solution is expected to increase overall 
> write performance while improving CPU utilization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13896) Improving Cassandra write performance

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-13896:
---
Fix Version/s: (was: 3.10)
   4.x

> Improving Cassandra write performance  
> ---
>
> Key: CASSANDRA-13896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13896
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
> Environment: Skylake server with 2 sockets, 192GB RAM, 3xPCIe SSDs
> OS: Centos 7.3 
> Java: Oracle JDK1.8.0_121
>Reporter: Prince Nana Owusu Boateng
> Fix For: 4.x
>
> Attachments: Screen Shot 2017-09-22 at 11.22.43 AM.png
>
>
> During our Cassandra performance testing, we see high percentage of the CPU 
> spent in *org.apache.cassandra.utils.memory.SlabAllocator.allocate(int, 
> OpOrder Group) * method.  Appears to be high contention of the 
> ** atomic Integer in write workloads.   This structure is 
> used by the threads for keeping track of the region bytebuffer allocation.  
> When the contention appears, adding more clients, modifications of write 
> specific parameters does not change write throughput performance.  Attached 
> are the details of Java Flight Recorder (JFR), showing hot functions.   When 
> we see this contention, we still have plenty of CPU and throughput left ( 
> *<20%*  Total average CPU utilization and * <11%* of the storage write total 
> throughput).   This occurs on Cassandra 3.10.0-src version using the 
> Cassandra-Stress.
> Proposal:
> We will like to introduce a solution which eliminates the atomic operations 
> on the ** atomic Integer. This implementation will allow 
> concurrent allocation of bytebuffers without an atomic compareAndSet and 
> incrementAndGet operations. The solution is expected to increase overall 
> write performance while improving CPU utilization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-12961) LCS needlessly checks for L0 STCS candidates multiple times

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-12961:


You can setup circleci by linking your github account at https://circleci.com/ 
- you can grant read-only access to public repositories such as cassandra, and 
it will automatically build new branches as you push. 

I havent yet investigated the failures, but I did note that there are repeated 
failures. I'm not yet sure if they're real or environmental.

> LCS needlessly checks for L0 STCS candidates multiple times
> ---
>
> Key: CASSANDRA-12961
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12961
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Jeff Jirsa
>Assignee: Vusal Ahmadoglu
>Priority: Trivial
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 
> 0001-CASSANDRA-12961-Moving-getSTCSInL0CompactionCandidat.patch
>
>
> It's very likely that the check for L0 STCS candidates (if L0 is falling 
> behind) can be moved outside of the loop, or at very least made so that it's 
> not called on each loop iteration:
> {code}
> for (int i = generations.length - 1; i > 0; i--)
> {
> List sstables = getLevel(i);
> if (sstables.isEmpty())
> continue; // mostly this just avoids polluting the debug log 
> with zero scores
> // we want to calculate score excluding compacting ones
> Set sstablesInLevel = Sets.newHashSet(sstables);
> Set remaining = Sets.difference(sstablesInLevel, 
> cfs.getTracker().getCompacting());
> double score = (double) SSTableReader.getTotalBytes(remaining) / 
> (double)maxBytesForLevel(i, maxSSTableSizeInBytes);
> logger.trace("Compaction score for level {} is {}", i, score);
> if (score > 1.001)
> {
> // before proceeding with a higher level, let's see if L0 is 
> far enough behind to warrant STCS
> CompactionCandidate l0Compaction = 
> getSTCSInL0CompactionCandidate();
> if (l0Compaction != null)
> return l0Compaction;
> ..
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-12961) LCS needlessly checks for L0 STCS candidates multiple times

[Vusal Ahmadoglu (JIRA)]

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

Vusal Ahmadoglu commented on CASSANDRA-12961:
-

Hi, Jeff. I can see that tests are failing. Is there anything I can help? Sorry 
for bothering you, I want to setup Circle CI to be able to run tests, could you 
suggest me resource about how can I set up and run C* tests in Circle CI?

> LCS needlessly checks for L0 STCS candidates multiple times
> ---
>
> Key: CASSANDRA-12961
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12961
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Jeff Jirsa
>Assignee: Vusal Ahmadoglu
>Priority: Trivial
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 
> 0001-CASSANDRA-12961-Moving-getSTCSInL0CompactionCandidat.patch
>
>
> It's very likely that the check for L0 STCS candidates (if L0 is falling 
> behind) can be moved outside of the loop, or at very least made so that it's 
> not called on each loop iteration:
> {code}
> for (int i = generations.length - 1; i > 0; i--)
> {
> List sstables = getLevel(i);
> if (sstables.isEmpty())
> continue; // mostly this just avoids polluting the debug log 
> with zero scores
> // we want to calculate score excluding compacting ones
> Set sstablesInLevel = Sets.newHashSet(sstables);
> Set remaining = Sets.difference(sstablesInLevel, 
> cfs.getTracker().getCompacting());
> double score = (double) SSTableReader.getTotalBytes(remaining) / 
> (double)maxBytesForLevel(i, maxSSTableSizeInBytes);
> logger.trace("Compaction score for level {} is {}", i, score);
> if (score > 1.001)
> {
> // before proceeding with a higher level, let's see if L0 is 
> far enough behind to warrant STCS
> CompactionCandidate l0Compaction = 
> getSTCSInL0CompactionCandidate();
> if (l0Compaction != null)
> return l0Compaction;
> ..
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13893) Column name "AGE" is being created as "414745" (ASCII values)

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13893:


Does not repro in 3.0:

{code}
cqlsh> create keyspace "Test" with replication = {'class': 
'NetworkTopologyStrategy', 'datacenter1': 2};
cqlsh> create table "Test".test ( id int primary key, "AGE" text);
cqlsh> describe "Test".test;

CREATE TABLE "Test".test (
id int PRIMARY KEY,
"AGE" text
) WITH bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{code}


> Column name "AGE" is being created as "414745" (ASCII values)
> -
>
> Key: CASSANDRA-13893
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13893
> Project: Cassandra
>  Issue Type: Bug
> Environment: Ubuntu 14
>Reporter: karthik
>
> Command: 
> {code:java}
> CREATE TABLE test (id text, "AGE" text, primary key(id));
> {code}
> Result for DESCRIBE TABLE test:
> {code:java}
> CREATE TABLE "myKeyspace".test (
> id text PRIMARY KEY,
> "414745" text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (CASSANDRA-13853) nodetool describecluster should be more informative

[Preetika Tyagi (JIRA)]

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

Preetika Tyagi reassigned CASSANDRA-13853:
--

Assignee: Preetika Tyagi

> nodetool describecluster should be more informative
> ---
>
> Key: CASSANDRA-13853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13853
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jon Haddad
>Assignee: Preetika Tyagi
>
> Additional information we should be displaying:
> * Total node count
> * List of datacenters, RF, with number of nodes per dc, how many are down, 
> * Version(s)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13896) Improving Cassandra write performance

[Prince Nana Owusu Boateng (JIRA)]

Prince Nana Owusu Boateng created CASSANDRA-13896:
-

 Summary: Improving Cassandra write performance  
 Key: CASSANDRA-13896
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13896
 Project: Cassandra
  Issue Type: Improvement
  Components: Local Write-Read Paths
 Environment: Skylake server with 2 sockets, 192GB RAM, 3xPCIe SSDs
OS: Centos 7.3 
Java: Oracle JDK1.8.0_121
Reporter: Prince Nana Owusu Boateng
 Fix For: 3.10
 Attachments: Screen Shot 2017-09-22 at 11.22.43 AM.png

During our Cassandra performance testing, we see high percentage of the CPU 
spent in *org.apache.cassandra.utils.memory.SlabAllocator.allocate(int, OpOrder 
Group) * method.  Appears to be high contention of the ** 
atomic Integer in write workloads.   This structure is used by the threads for 
keeping track of the region bytebuffer allocation.  When the contention 
appears, adding more clients, modifications of write specific parameters does 
not change write throughput performance.  Attached are the details of Java 
Flight Recorder (JFR), showing hot functions.   When we see this contention, we 
still have plenty of CPU and throughput left ( *<20%*  Total average CPU 
utilization and * <11%* of the storage write total throughput).   This occurs 
on Cassandra 3.10.0-src version using the Cassandra-Stress.

Proposal:
We will like to introduce a solution which eliminates the atomic operations on 
the ** atomic Integer. This implementation will allow 
concurrent allocation of bytebuffers without an atomic compareAndSet and 
incrementAndGet operations. The solution is expected to increase overall write 
performance while improving CPU utilization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13893) Column name "AGE" is being created as "414745" (ASCII values)

[Preetika Tyagi (JIRA)]

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

Preetika Tyagi edited comment on CASSANDRA-13893 at 9/22/17 6:09 PM:
-

I don't see this issue.
Below is what I tried:

CREATE KEYSPACE demodb WITH REPLICATION = { 'class' : 
'NetworkTopologyStrategy', 'datacenter1' : 3 };
USE demodb;
CREATE TABLE test (id text, "AGE" text, primary key(id));
DESCRIBE TABLE test;

CREATE TABLE demodb.test (
id text PRIMARY KEY,
"AGE" text
) WITH bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';


was (Author: preetikatyagi):
I don't see this issue.
Below is what I tried:

CREATE KEYSPACE demodb WITH REPLICATION = { 'class' : 
'NetworkTopologyStrategy', 'datacenter1' : 3 };
USE demodb;
CREATE TABLE test (id text, "AGE" text, primary key(id));
DESCRIBE TABLE test;

CREATE TABLE demodb.test (
id text PRIMARY KEY,
"AGE" text
) WITH bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';

> Column name "AGE" is being created as "414745" (ASCII values)
> -
>
> Key: CASSANDRA-13893
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13893
> Project: Cassandra
>  Issue Type: Bug
> Environment: Ubuntu 14
>Reporter: karthik
>
> Command: 
> {code:java}
> CREATE TABLE test (id text, "AGE" text, primary key(id));
> {code}
> Result for DESCRIBE TABLE test:
> {code:java}
> CREATE TABLE "myKeyspace".test (
> id text PRIMARY KEY,
> "414745" text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13893) Column name "AGE" is being created as "414745" (ASCII values)

[Preetika Tyagi (JIRA)]

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

Preetika Tyagi commented on CASSANDRA-13893:


I don't see this issue.
Below is what I tried:

CREATE KEYSPACE demodb WITH REPLICATION = { 'class' : 
'NetworkTopologyStrategy', 'datacenter1' : 3 };
USE demodb ;
CREATE TABLE test (id text, "AGE" text, primary key(id));
DESCRIBE TABLE test ;
CREATE TABLE demodb.test (
id text PRIMARY KEY,
"AGE" text
) WITH bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';

> Column name "AGE" is being created as "414745" (ASCII values)
> -
>
> Key: CASSANDRA-13893
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13893
> Project: Cassandra
>  Issue Type: Bug
> Environment: Ubuntu 14
>Reporter: karthik
>
> Command: 
> {code:java}
> CREATE TABLE test (id text, "AGE" text, primary key(id));
> {code}
> Result for DESCRIBE TABLE test:
> {code:java}
> CREATE TABLE "myKeyspace".test (
> id text PRIMARY KEY,
> "414745" text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13893) Column name "AGE" is being created as "414745" (ASCII values)

[Preetika Tyagi (JIRA)]

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

Preetika Tyagi edited comment on CASSANDRA-13893 at 9/22/17 6:08 PM:
-

I don't see this issue.
Below is what I tried:

CREATE KEYSPACE demodb WITH REPLICATION = { 'class' : 
'NetworkTopologyStrategy', 'datacenter1' : 3 };
USE demodb;
CREATE TABLE test (id text, "AGE" text, primary key(id));
DESCRIBE TABLE test;

CREATE TABLE demodb.test (
id text PRIMARY KEY,
"AGE" text
) WITH bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';


was (Author: preetikatyagi):
I don't see this issue.
Below is what I tried:

CREATE KEYSPACE demodb WITH REPLICATION = { 'class' : 
'NetworkTopologyStrategy', 'datacenter1' : 3 };
USE demodb ;
CREATE TABLE test (id text, "AGE" text, primary key(id));
DESCRIBE TABLE test ;
CREATE TABLE demodb.test (
id text PRIMARY KEY,
"AGE" text
) WITH bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';

> Column name "AGE" is being created as "414745" (ASCII values)
> -
>
> Key: CASSANDRA-13893
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13893
> Project: Cassandra
>  Issue Type: Bug
> Environment: Ubuntu 14
>Reporter: karthik
>
> Command: 
> {code:java}
> CREATE TABLE test (id text, "AGE" text, primary key(id));
> {code}
> Result for DESCRIBE TABLE test:
> {code:java}
> CREATE TABLE "myKeyspace".test (
> id text PRIMARY KEY,
> "414745" text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13895) IOException unwrapping in CommitLogReader. readCommitLogSegment misses exceptions in resource creation block

[Catalin Grigoroscuta (JIRA)]

Catalin Grigoroscuta created CASSANDRA-13895:


 Summary: IOException unwrapping in CommitLogReader. 
readCommitLogSegment misses exceptions in resource creation block
 Key: CASSANDRA-13895
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13895
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Catalin Grigoroscuta
Priority: Minor


CommitLogReader. readCommitLogSegment is unwrapping IOExceptions wrapped as 
RuntimeExceptions using a try-with-resource block.

However, the resource specification block, {{RandomAccessReader reader = 
RandomAccessReader.open(file)}}, could also throw such an exception, which is 
missed by the catch block and throws as a RuntimeException instead of an 
IOException. 

One such example that I've seen is: 
- RandomAccessReader.open (called in try-with-resource resource specification 
block initialization)
- ChannelProxy(File) constructor 
- ChannelProxy.openChannel (wraps IOException as RuntimeException) 

I don't know what the impact in Cassandra could be, I ran into this while 
processing CDC/commit logs for synchronization with another system.
Was using Cassandra 3.11.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13595) Short read protection doesn't work at the end of a partition

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-13595:
---

Ok first cut, but there are some major issues with it.

1. You can't rely on the class of the command to determine if it's a single 
partition or a range read command. We do use range read commands for indexed 
queries even when the partition key is set. See CASSANDRA-11617 and 
CASSANDRA-11872 for some more context.

2. You cannot use {{command.limits().forShortReadRetry()}} method for the new 
limits here. It wasn't written with ranged reads in mind, and does among other 
things throw away the per partition limit - not what you want to happen.

3. The command created doesn't get passed original {{command.isForThrift()}} 
and hardcodes it as {{false}}. This was an issue with row-level SRP as well, 
but I fixed it yesterday. Should be using 
{{PartitionRangeReadCommand.withUpdatedLimitsAndDataRange()}} instead. As a 
bonus, it preserves the correct {{indexMetadata}} so you don't have to do an 
extra lookup.

4. I don't think that new range calculation is correct, and accounts for 
collisions of multiple partitions keys mapping to tokens.

5. {{shouldDoPartitionShortReadProtection()}} can be written a lot simpler, and 
some is redundant. {{if (mergedResultCounter.counted() >= 
command.limits().count())}} can't ever be true (but also is equivalent to {{if 
(mergedResultCounter.isDone())}}). The only meaningful thing you can do here is
{code}
// if the returned partition doesn't have enough partitions/rows to 
satisfy even the original limit, don't ask for more
if (!singleResultCounter.isDone())
return null;
{code}
, to be honest.

6. I'm not a huge fan of the way {{expectedRows}} is shared between two 
protections, and am not sure it's correct.

7. The metric for SRP requests isn't being incremented.

I have a version of this that fixes most of these. Needs some more work and 
manual testing, and eventually approval. It's a bit urgent for me, so do you 
mind if I take it over from this point? Thanks.

> Short read protection doesn't work at the end of a partition
> 
>
> Key: CASSANDRA-13595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13595
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Andrés de la Peña
>Assignee: ZhaoYang
>  Labels: Correctness
>
> It seems that short read protection doesn't work when the short read is done 
> at the end of a partition in a range query. The final assertion of this dtest 
> fails:
> {code}
> def short_read_partitions_delete_test(self):
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled': 
> False})
> cluster.set_batch_commitlog(enabled=True)
> cluster.populate(2).start(wait_other_notice=True)
> node1, node2 = self.cluster.nodelist()
> session = self.patient_cql_connection(node1)
> create_ks(session, 'ks', 2)
> session.execute("CREATE TABLE t (k int, c int, PRIMARY KEY(k, c)) 
> WITH read_repair_chance = 0.0")
> # we write 1 and 2 in a partition: all nodes get it.
> session.execute(SimpleStatement("INSERT INTO t (k, c) VALUES (1, 1)", 
> consistency_level=ConsistencyLevel.ALL))
> session.execute(SimpleStatement("INSERT INTO t (k, c) VALUES (2, 1)", 
> consistency_level=ConsistencyLevel.ALL))
> # we delete partition 1: only node 1 gets it.
> node2.flush()
> node2.stop(wait_other_notice=True)
> session = self.patient_cql_connection(node1, 'ks', 
> consistency_level=ConsistencyLevel.ONE)
> session.execute(SimpleStatement("DELETE FROM t WHERE k = 1"))
> node2.start(wait_other_notice=True)
> # we delete partition 2: only node 2 gets it.
> node1.flush()
> node1.stop(wait_other_notice=True)
> session = self.patient_cql_connection(node2, 'ks', 
> consistency_level=ConsistencyLevel.ONE)
> session.execute(SimpleStatement("DELETE FROM t WHERE k = 2"))
> node1.start(wait_other_notice=True)
> # read from both nodes
> session = self.patient_cql_connection(node1, 'ks', 
> consistency_level=ConsistencyLevel.ALL)
> assert_none(session, "SELECT * FROM t LIMIT 1")
> {code}
> However, the dtest passes if we remove the {{LIMIT 1}}.
> Short read protection [uses a 
> {{SinglePartitionReadCommand}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/DataResolver.java#L484],
>  maybe it should use a {{PartitionRangeReadCommand}} instead?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CASSANDRA-13894) TriggerExecutor ignored original PartitionUpdate

[ZhaoYang (JIRA)]

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

ZhaoYang commented on CASSANDRA-13894:
--

Thanks for reviewing

> TriggerExecutor ignored original PartitionUpdate
> 
>
> Key: CASSANDRA-13894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13894
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: ZhaoYang
>Assignee: ZhaoYang
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> Since 3.0, the 
> [TriggerExecutor.execute(PartitionUpdate)|https://github.com/jasonstack/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/triggers/TriggerExecutor.java#L82-L89]
>  will only return augmented mutation, ignoring original update..
> [Test|https://github.com/jasonstack/cassandra/commit/eb28844035242c4cb73c5148254f34672f2325da]to
>  reproduce.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13894) TriggerExecutor ignored original PartitionUpdate

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-13894:

   Resolution: Fixed
Fix Version/s: (was: 3.11.x)
   (was: 4.x)
   (was: 3.0.x)
   4.0
   3.11.1
   3.0.15
   Status: Resolved  (was: Patch Available)

> TriggerExecutor ignored original PartitionUpdate
> 
>
> Key: CASSANDRA-13894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13894
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: ZhaoYang
>Assignee: ZhaoYang
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> Since 3.0, the 
> [TriggerExecutor.execute(PartitionUpdate)|https://github.com/jasonstack/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/triggers/TriggerExecutor.java#L82-L89]
>  will only return augmented mutation, ignoring original update..
> [Test|https://github.com/jasonstack/cassandra/commit/eb28844035242c4cb73c5148254f34672f2325da]to
>  reproduce.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13894) TriggerExecutor ignored original PartitionUpdate

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-13894:
-

Good catch! Fix LGTM. Committed as {{51e6f2446e71c8bd2ce89480b7d30d5b9ed1546e}} 
and merge up to cassandra-3.11 and trunk. Thanks!

> TriggerExecutor ignored original PartitionUpdate
> 
>
> Key: CASSANDRA-13894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13894
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: ZhaoYang
>Assignee: ZhaoYang
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Since 3.0, the 
> [TriggerExecutor.execute(PartitionUpdate)|https://github.com/jasonstack/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/triggers/TriggerExecutor.java#L82-L89]
>  will only return augmented mutation, ignoring original update..
> [Test|https://github.com/jasonstack/cassandra/commit/eb28844035242c4cb73c5148254f34672f2325da]to
>  reproduce.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[paulo]

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: 756fab87c97a7a03fcf6495af166d5193fa4e6ae
Parents: f1b7d6e 0e5c84a
Author: Paulo Motta 
Authored: Fri Sep 22 09:43:38 2017 -0500
Committer: Paulo Motta 
Committed: Fri Sep 22 09:44:02 2017 -0500

--
 .../cassandra/triggers/TriggerExecutor.java |  7 +-
 .../cassandra/triggers/TriggerExecutorTest.java | 26 +++-
 .../apache/cassandra/triggers/TriggersTest.java | 24 +++---
 3 files changed, 41 insertions(+), 16 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/756fab87/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
--
diff --cc src/java/org/apache/cassandra/triggers/TriggerExecutor.java
index 906b342,0354fde..754183f
--- a/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
+++ b/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
@@@ -87,7 -86,12 +87,12 @@@ public class TriggerExecuto
  if (intermediate == null || intermediate.isEmpty())
  return updates;
  
- return 
PartitionUpdate.merge(validateForSinglePartition(updates.metadata().id, 
updates.partitionKey(), intermediate));
 -List augmented = 
validateForSinglePartition(updates.metadata().cfId,
++List augmented = 
validateForSinglePartition(updates.metadata().id,
+  
updates.partitionKey(),
+  
intermediate);
+ // concatenate augmented and origin
+ augmented.add(updates);
+ return PartitionUpdate.merge(augmented);
  }
  
  /**

http://git-wip-us.apache.org/repos/asf/cassandra/blob/756fab87/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
--
diff --cc test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
index a796daf,0e4130d..aa5ee9b
--- a/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
+++ b/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
@@@ -33,7 -33,6 +33,8 @@@ import org.apache.cassandra.db.partitio
  import org.apache.cassandra.exceptions.ConfigurationException;
  import org.apache.cassandra.exceptions.InvalidRequestException;
  import org.apache.cassandra.schema.TriggerMetadata;
 +import org.apache.cassandra.schema.Triggers;
++import org.apache.cassandra.triggers.TriggerExecutorTest.SameKeySameCfTrigger;
  import org.apache.cassandra.utils.FBUtilities;
  
  import static org.apache.cassandra.utils.ByteBufferUtil.bytes;
@@@ -52,17 -51,30 +53,30 @@@ public class TriggerExecutorTes
  @Test
  public void sameKeySameCfColumnFamilies() throws ConfigurationException, 
InvalidRequestException
  {
 -CFMetaData metadata = makeCfMetaData("ks1", "cf1", 
TriggerMetadata.create("test", SameKeySameCfTrigger.class.getName()));
 +TableMetadata metadata = makeTableMetadata("ks1", "cf1", 
TriggerMetadata.create("test", SameKeySameCfTrigger.class.getName()));
+ // origin column 'c1' = "v1", augment extra column 'c2' = "trigger"
  PartitionUpdate mutated = 
TriggerExecutor.instance.execute(makeCf(metadata, "k1", "v1", null));
  
- try (RowIterator rowIterator = 
UnfilteredRowIterators.filter(mutated.unfilteredIterator(),
-  
FBUtilities.nowInSeconds()))
+ List rows = new ArrayList<>();
+ try (RowIterator iterator = 
UnfilteredRowIterators.filter(mutated.unfilteredIterator(),
+   
FBUtilities.nowInSeconds()))
  {
- Iterator cells = rowIterator.next().cells().iterator();
- assertEquals(bytes("trigger"), cells.next().value());
- 
- assertTrue(!rowIterator.hasNext());
+ iterator.forEachRemaining(rows::add);
  }
+ 
+ // only 1 row
+ assertEquals(1, rows.size());
+ 
+ List cells = new ArrayList<>();
+ rows.get(0).cells().forEach(cells::add);
+ 
+ // 2 columns
+ assertEquals(2, cells.size());
+ 
+ // check column 'c1'
+ assertEquals(bytes("v1"), cells.get(0).value());
+ // check column 'c2'
+ assertEquals(bytes("trigger"), cells.get(1).value());
  }
  
  @Test(expected = InvalidRequestException.class)

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

[paulo]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/trunk
Commit: 0e5c84ad8f5b43ff98b72ccdc62718bb2795b711
Parents: de6f21f 51e6f24
Author: Paulo Motta 
Authored: Fri Sep 22 09:42:36 2017 -0500
Committer: Paulo Motta 
Committed: Fri Sep 22 09:42:43 2017 -0500

--
 .../cassandra/triggers/TriggerExecutor.java |  7 -
 .../cassandra/triggers/TriggerExecutorTest.java | 25 
 .../apache/cassandra/triggers/TriggersTest.java | 30 
 3 files changed, 43 insertions(+), 19 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0e5c84ad/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0e5c84ad/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0e5c84ad/test/unit/org/apache/cassandra/triggers/TriggersTest.java
--
diff --cc test/unit/org/apache/cassandra/triggers/TriggersTest.java
index e5a2dd6,67619dc..165a7fe
--- a/test/unit/org/apache/cassandra/triggers/TriggersTest.java
+++ b/test/unit/org/apache/cassandra/triggers/TriggersTest.java
@@@ -192,10 -194,12 +192,10 @@@ public class TriggersTes
 org.apache.cassandra.thrift.ConsistencyLevel.LOCAL_SERIAL,
 org.apache.cassandra.thrift.ConsistencyLevel.ONE);
  
- assertUpdateIsAugmented(6);
+ assertUpdateIsAugmented(6, "v1", 6);
  }
  
 -// Unfortunately, an IRE thrown from StorageProxy.cas
 -// results in a RuntimeException from QueryProcessor.process
 -@Test(expected=RuntimeException.class)
 +
@Test(expected=org.apache.cassandra.exceptions.InvalidRequestException.class)
  public void 
onCqlUpdateWithConditionsRejectGeneratedUpdatesForDifferentPartition() throws 
Exception
  {
  String cf = "cf" + System.nanoTime();


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

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

[paulo]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/cassandra-3.11
Commit: 0e5c84ad8f5b43ff98b72ccdc62718bb2795b711
Parents: de6f21f 51e6f24
Author: Paulo Motta 
Authored: Fri Sep 22 09:42:36 2017 -0500
Committer: Paulo Motta 
Committed: Fri Sep 22 09:42:43 2017 -0500

--
 .../cassandra/triggers/TriggerExecutor.java |  7 -
 .../cassandra/triggers/TriggerExecutorTest.java | 25 
 .../apache/cassandra/triggers/TriggersTest.java | 30 
 3 files changed, 43 insertions(+), 19 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0e5c84ad/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0e5c84ad/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0e5c84ad/test/unit/org/apache/cassandra/triggers/TriggersTest.java
--
diff --cc test/unit/org/apache/cassandra/triggers/TriggersTest.java
index e5a2dd6,67619dc..165a7fe
--- a/test/unit/org/apache/cassandra/triggers/TriggersTest.java
+++ b/test/unit/org/apache/cassandra/triggers/TriggersTest.java
@@@ -192,10 -194,12 +192,10 @@@ public class TriggersTes
 org.apache.cassandra.thrift.ConsistencyLevel.LOCAL_SERIAL,
 org.apache.cassandra.thrift.ConsistencyLevel.ONE);
  
- assertUpdateIsAugmented(6);
+ assertUpdateIsAugmented(6, "v1", 6);
  }
  
 -// Unfortunately, an IRE thrown from StorageProxy.cas
 -// results in a RuntimeException from QueryProcessor.process
 -@Test(expected=RuntimeException.class)
 +
@Test(expected=org.apache.cassandra.exceptions.InvalidRequestException.class)
  public void 
onCqlUpdateWithConditionsRejectGeneratedUpdatesForDifferentPartition() throws 
Exception
  {
  String cf = "cf" + System.nanoTime();


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

[1/6] cassandra git commit: Fix missing original update in TriggerExecutor

[paulo]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 2b897d2de -> 51e6f2446
  refs/heads/cassandra-3.11 de6f21f58 -> 0e5c84ad8
  refs/heads/trunk f1b7d6e8e -> 756fab87c


Fix missing original update in TriggerExecutor

Patch by Jason Stack; Reviewed by Paulo Motta for CASSANDRA-13894


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

Branch: refs/heads/cassandra-3.0
Commit: 51e6f2446e71c8bd2ce89480b7d30d5b9ed1546e
Parents: 2b897d2
Author: Zhao Yang 
Authored: Fri Sep 22 17:04:05 2017 +0800
Committer: Paulo Motta 
Committed: Fri Sep 22 09:39:29 2017 -0500

--
 CHANGES.txt |  1 +
 .../cassandra/triggers/TriggerExecutor.java |  7 -
 .../cassandra/triggers/TriggerExecutorTest.java | 23 ---
 .../apache/cassandra/triggers/TriggersTest.java | 30 
 4 files changed, 44 insertions(+), 17 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/51e6f244/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 91f5a51..68da81a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.15
+ * Fix missing original update in TriggerExecutor (CASSANDRA-13894)
  * Remove non-rpc-ready nodes from counter leader candidates (CASSANDRA-13043)
  * Improve short read protection performance (CASSANDRA-13794)
  * Fix sstable reader to support range-tombstone-marker for multi-slices 
(CASSANDRA-13787)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/51e6f244/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
--
diff --git a/src/java/org/apache/cassandra/triggers/TriggerExecutor.java 
b/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
index 40d4094..3996127 100644
--- a/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
+++ b/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
@@ -85,7 +85,12 @@ public class TriggerExecutor
 if (intermediate == null || intermediate.isEmpty())
 return updates;
 
-return 
PartitionUpdate.merge(validateForSinglePartition(updates.metadata().cfId, 
updates.partitionKey(), intermediate));
+List augmented = 
validateForSinglePartition(updates.metadata().cfId,
+ 
updates.partitionKey(),
+ 
intermediate);
+// concatenate augmented and origin
+augmented.add(updates);
+return PartitionUpdate.merge(augmented);
 }
 
 /**

http://git-wip-us.apache.org/repos/asf/cassandra/blob/51e6f244/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
--
diff --git a/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java 
b/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
index 44391c8..d3c6961 100644
--- a/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
+++ b/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
@@ -44,14 +44,29 @@ public class TriggerExecutorTest
 public void sameKeySameCfColumnFamilies() throws ConfigurationException, 
InvalidRequestException
 {
 CFMetaData metadata = makeCfMetaData("ks1", "cf1", 
TriggerMetadata.create("test", SameKeySameCfTrigger.class.getName()));
+// origin column 'c1' = "v1", augment extra column 'c2' = "trigger"
 PartitionUpdate mutated = 
TriggerExecutor.instance.execute(makeCf(metadata, "k1", "v1", null));
 
-RowIterator rowIterator = 
UnfilteredRowIterators.filter(mutated.unfilteredIterator(), 
FBUtilities.nowInSeconds());
+List rows = new ArrayList<>();
+try (RowIterator iterator = 
UnfilteredRowIterators.filter(mutated.unfilteredIterator(),
+  
FBUtilities.nowInSeconds()))
+{
+iterator.forEachRemaining(rows::add);
+}
+
+// only 1 row
+assertEquals(1, rows.size());
+
+List cells = new ArrayList<>();
+rows.get(0).cells().forEach(cells::add);
 
-Iterator cells = rowIterator.next().cells().iterator();
-assertEquals(bytes("trigger"), cells.next().value());
+// 2 columns
+assertEquals(2, cells.size());
 
-assertTrue(!rowIterator.hasNext());
+// check column 'c1'
+assertEquals(bytes("v1"), cells.get(0).value());
+// check column 

[2/6] cassandra git commit: Fix missing original update in TriggerExecutor

[paulo]

Fix missing original update in TriggerExecutor

Patch by Jason Stack; Reviewed by Paulo Motta for CASSANDRA-13894


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

Branch: refs/heads/cassandra-3.11
Commit: 51e6f2446e71c8bd2ce89480b7d30d5b9ed1546e
Parents: 2b897d2
Author: Zhao Yang 
Authored: Fri Sep 22 17:04:05 2017 +0800
Committer: Paulo Motta 
Committed: Fri Sep 22 09:39:29 2017 -0500

--
 CHANGES.txt |  1 +
 .../cassandra/triggers/TriggerExecutor.java |  7 -
 .../cassandra/triggers/TriggerExecutorTest.java | 23 ---
 .../apache/cassandra/triggers/TriggersTest.java | 30 
 4 files changed, 44 insertions(+), 17 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/51e6f244/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 91f5a51..68da81a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.15
+ * Fix missing original update in TriggerExecutor (CASSANDRA-13894)
  * Remove non-rpc-ready nodes from counter leader candidates (CASSANDRA-13043)
  * Improve short read protection performance (CASSANDRA-13794)
  * Fix sstable reader to support range-tombstone-marker for multi-slices 
(CASSANDRA-13787)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/51e6f244/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
--
diff --git a/src/java/org/apache/cassandra/triggers/TriggerExecutor.java 
b/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
index 40d4094..3996127 100644
--- a/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
+++ b/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
@@ -85,7 +85,12 @@ public class TriggerExecutor
 if (intermediate == null || intermediate.isEmpty())
 return updates;
 
-return 
PartitionUpdate.merge(validateForSinglePartition(updates.metadata().cfId, 
updates.partitionKey(), intermediate));
+List augmented = 
validateForSinglePartition(updates.metadata().cfId,
+ 
updates.partitionKey(),
+ 
intermediate);
+// concatenate augmented and origin
+augmented.add(updates);
+return PartitionUpdate.merge(augmented);
 }
 
 /**

http://git-wip-us.apache.org/repos/asf/cassandra/blob/51e6f244/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
--
diff --git a/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java 
b/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
index 44391c8..d3c6961 100644
--- a/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
+++ b/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
@@ -44,14 +44,29 @@ public class TriggerExecutorTest
 public void sameKeySameCfColumnFamilies() throws ConfigurationException, 
InvalidRequestException
 {
 CFMetaData metadata = makeCfMetaData("ks1", "cf1", 
TriggerMetadata.create("test", SameKeySameCfTrigger.class.getName()));
+// origin column 'c1' = "v1", augment extra column 'c2' = "trigger"
 PartitionUpdate mutated = 
TriggerExecutor.instance.execute(makeCf(metadata, "k1", "v1", null));
 
-RowIterator rowIterator = 
UnfilteredRowIterators.filter(mutated.unfilteredIterator(), 
FBUtilities.nowInSeconds());
+List rows = new ArrayList<>();
+try (RowIterator iterator = 
UnfilteredRowIterators.filter(mutated.unfilteredIterator(),
+  
FBUtilities.nowInSeconds()))
+{
+iterator.forEachRemaining(rows::add);
+}
+
+// only 1 row
+assertEquals(1, rows.size());
+
+List cells = new ArrayList<>();
+rows.get(0).cells().forEach(cells::add);
 
-Iterator cells = rowIterator.next().cells().iterator();
-assertEquals(bytes("trigger"), cells.next().value());
+// 2 columns
+assertEquals(2, cells.size());
 
-assertTrue(!rowIterator.hasNext());
+// check column 'c1'
+assertEquals(bytes("v1"), cells.get(0).value());
+// check column 'c2'
+assertEquals(bytes("trigger"), cells.get(1).value());
 }
 
 @Test(expected = InvalidRequestException.class)

[3/6] cassandra git commit: Fix missing original update in TriggerExecutor

[paulo]

Fix missing original update in TriggerExecutor

Patch by Jason Stack; Reviewed by Paulo Motta for CASSANDRA-13894


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

Branch: refs/heads/trunk
Commit: 51e6f2446e71c8bd2ce89480b7d30d5b9ed1546e
Parents: 2b897d2
Author: Zhao Yang 
Authored: Fri Sep 22 17:04:05 2017 +0800
Committer: Paulo Motta 
Committed: Fri Sep 22 09:39:29 2017 -0500

--
 CHANGES.txt |  1 +
 .../cassandra/triggers/TriggerExecutor.java |  7 -
 .../cassandra/triggers/TriggerExecutorTest.java | 23 ---
 .../apache/cassandra/triggers/TriggersTest.java | 30 
 4 files changed, 44 insertions(+), 17 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/51e6f244/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 91f5a51..68da81a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.15
+ * Fix missing original update in TriggerExecutor (CASSANDRA-13894)
  * Remove non-rpc-ready nodes from counter leader candidates (CASSANDRA-13043)
  * Improve short read protection performance (CASSANDRA-13794)
  * Fix sstable reader to support range-tombstone-marker for multi-slices 
(CASSANDRA-13787)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/51e6f244/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
--
diff --git a/src/java/org/apache/cassandra/triggers/TriggerExecutor.java 
b/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
index 40d4094..3996127 100644
--- a/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
+++ b/src/java/org/apache/cassandra/triggers/TriggerExecutor.java
@@ -85,7 +85,12 @@ public class TriggerExecutor
 if (intermediate == null || intermediate.isEmpty())
 return updates;
 
-return 
PartitionUpdate.merge(validateForSinglePartition(updates.metadata().cfId, 
updates.partitionKey(), intermediate));
+List augmented = 
validateForSinglePartition(updates.metadata().cfId,
+ 
updates.partitionKey(),
+ 
intermediate);
+// concatenate augmented and origin
+augmented.add(updates);
+return PartitionUpdate.merge(augmented);
 }
 
 /**

http://git-wip-us.apache.org/repos/asf/cassandra/blob/51e6f244/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
--
diff --git a/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java 
b/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
index 44391c8..d3c6961 100644
--- a/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
+++ b/test/unit/org/apache/cassandra/triggers/TriggerExecutorTest.java
@@ -44,14 +44,29 @@ public class TriggerExecutorTest
 public void sameKeySameCfColumnFamilies() throws ConfigurationException, 
InvalidRequestException
 {
 CFMetaData metadata = makeCfMetaData("ks1", "cf1", 
TriggerMetadata.create("test", SameKeySameCfTrigger.class.getName()));
+// origin column 'c1' = "v1", augment extra column 'c2' = "trigger"
 PartitionUpdate mutated = 
TriggerExecutor.instance.execute(makeCf(metadata, "k1", "v1", null));
 
-RowIterator rowIterator = 
UnfilteredRowIterators.filter(mutated.unfilteredIterator(), 
FBUtilities.nowInSeconds());
+List rows = new ArrayList<>();
+try (RowIterator iterator = 
UnfilteredRowIterators.filter(mutated.unfilteredIterator(),
+  
FBUtilities.nowInSeconds()))
+{
+iterator.forEachRemaining(rows::add);
+}
+
+// only 1 row
+assertEquals(1, rows.size());
+
+List cells = new ArrayList<>();
+rows.get(0).cells().forEach(cells::add);
 
-Iterator cells = rowIterator.next().cells().iterator();
-assertEquals(bytes("trigger"), cells.next().value());
+// 2 columns
+assertEquals(2, cells.size());
 
-assertTrue(!rowIterator.hasNext());
+// check column 'c1'
+assertEquals(bytes("v1"), cells.get(0).value());
+// check column 'c2'
+assertEquals(bytes("trigger"), cells.get(1).value());
 }
 
 @Test(expected = InvalidRequestException.class)

[jira] [Updated] (CASSANDRA-13893) Column name "AGE" is being created as "414745" (ASCII values)

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13893:
---
Since Version:   (was: 3.11.0)
 Priority: Major  (was: Critical)
Fix Version/s: (was: 3.11.0)

> Column name "AGE" is being created as "414745" (ASCII values)
> -
>
> Key: CASSANDRA-13893
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13893
> Project: Cassandra
>  Issue Type: Bug
> Environment: Ubuntu 14
>Reporter: karthik
>
> Command: 
> {code:java}
> CREATE TABLE test (id text, "AGE" text, primary key(id));
> {code}
> Result for DESCRIBE TABLE test:
> {code:java}
> CREATE TABLE "myKeyspace".test (
> id text PRIMARY KEY,
> "414745" text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-12373) 3.0 breaks CQL compatibility with super columns families

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-12373:
---

And thanks from me to you both. I had it assigned to me for review for too long 
and still couldn't find enough energy to do it. Sorry. It really is unfun - 
both to implement and to review. 

> 3.0 breaks CQL compatibility with super columns families
> 
>
> Key: CASSANDRA-12373
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12373
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Sylvain Lebresne
>Assignee: Alex Petrov
> Fix For: 3.0.x, 3.11.x
>
>
> This is a follow-up to CASSANDRA-12335 to fix the CQL side of super column 
> compatibility.
> The details and a proposed solution can be found in the comments of 
> CASSANDRA-12335 but the crux of the issue is that super column famillies show 
> up differently in CQL in 3.0.x/3.x compared to 2.x, hence breaking backward 
> compatibilty.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13894) TriggerExecutor ignored original PartitionUpdate

[ZhaoYang (JIRA)]

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

ZhaoYang commented on CASSANDRA-13894:
--

CircleCI passed. Failed some tests Internal CI , but seems not related, mostly 
on repair/sasi..

> TriggerExecutor ignored original PartitionUpdate
> 
>
> Key: CASSANDRA-13894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13894
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: ZhaoYang
>Assignee: ZhaoYang
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Since 3.0, the 
> [TriggerExecutor.execute(PartitionUpdate)|https://github.com/jasonstack/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/triggers/TriggerExecutor.java#L82-L89]
>  will only return augmented mutation, ignoring original update..
> [Test|https://github.com/jasonstack/cassandra/commit/eb28844035242c4cb73c5148254f34672f2325da]to
>  reproduce.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-12373) 3.0 breaks CQL compatibility with super columns families

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-12373:
--

Well, that's a +1 from me. Great job [~ifesdjeen] on this not-too-fun issue.

bq. Is this not too late for 3.0?

As Aleksey says, but I'll also add that it's actually fixing a breaking change 
from 2.x that could prevent some users from updating, so it really should be 
3.0.

> 3.0 breaks CQL compatibility with super columns families
> 
>
> Key: CASSANDRA-12373
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12373
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Sylvain Lebresne
>Assignee: Alex Petrov
> Fix For: 3.0.x, 3.11.x
>
>
> This is a follow-up to CASSANDRA-12335 to fix the CQL side of super column 
> compatibility.
> The details and a proposed solution can be found in the comments of 
> CASSANDRA-12335 but the crux of the issue is that super column famillies show 
> up differently in CQL in 3.0.x/3.x compared to 2.x, hence breaking backward 
> compatibilty.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13867) Make PartitionUpdate and Mutation immutable

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-13867:

 Reviewer: Aleksey Yeschenko
Fix Version/s: 4.x
   3.11.x
   3.0.x
   Status: Patch Available  (was: Open)

Only a 3.0 patch so far, will create the rest of the branches and run tests 
once this has been reviewed

https://github.com/krummas/cassandra/commits/marcuse/13867
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/334/
https://circleci.com/gh/krummas/cassandra/118


> Make PartitionUpdate and Mutation immutable
> ---
>
> Key: CASSANDRA-13867
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13867
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> To avoid issues like CASSANDRA-13619 we should make PartitionUpdate and 
> Mutation immutable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13892) Make BTree.Builder use the initialCapacity

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-13892:

Status: Patch Available  (was: Open)

looks better: https://circleci.com/gh/krummas/cassandra/116

> Make BTree.Builder use the initialCapacity
> --
>
> Key: CASSANDRA-13892
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13892
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> The initialCapacity passed to {{BTree.builder(comparator, initialCapacity)}} 
> is unused, start using it



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13894) TriggerExecutor ignored original PartitionUpdate

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-13894:

Reviewer: Paulo Motta

> TriggerExecutor ignored original PartitionUpdate
> 
>
> Key: CASSANDRA-13894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13894
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: ZhaoYang
>Assignee: ZhaoYang
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Since 3.0, the 
> [TriggerExecutor.execute(PartitionUpdate)|https://github.com/jasonstack/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/triggers/TriggerExecutor.java#L82-L89]
>  will only return augmented mutation, ignoring original update..
> [Test|https://github.com/jasonstack/cassandra/commit/eb28844035242c4cb73c5148254f34672f2325da]to
>  reproduce.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13894) TriggerExecutor ignored original PartitionUpdate

[ZhaoYang (JIRA)]

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

ZhaoYang updated CASSANDRA-13894:
-
Status: Patch Available  (was: Open)

> TriggerExecutor ignored original PartitionUpdate
> 
>
> Key: CASSANDRA-13894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13894
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: ZhaoYang
>Assignee: ZhaoYang
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Since 3.0, the 
> [TriggerExecutor.execute(PartitionUpdate)|https://github.com/jasonstack/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/triggers/TriggerExecutor.java#L82-L89]
>  will only return augmented mutation, ignoring original update..
> [Test|https://github.com/jasonstack/cassandra/commit/eb28844035242c4cb73c5148254f34672f2325da]to
>  reproduce.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13894) TriggerExecutor ignored original PartitionUpdate

[ZhaoYang (JIRA)]

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

ZhaoYang commented on CASSANDRA-13894:
--

| source |
| 
[trunk|https://github.com/jasonstack/cassandra/commits/trigger-missing-update] |
| 
[3.11|https://github.com/jasonstack/cassandra/commits/trigger-missing-update-3.11]
 |
| 
[3.0|https://github.com/jasonstack/cassandra/commits/trigger-missing-update-3.0]
 |

changes:  concatenate original PartitionUpdate with augmented updates.

> TriggerExecutor ignored original PartitionUpdate
> 
>
> Key: CASSANDRA-13894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13894
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: ZhaoYang
>Assignee: ZhaoYang
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Since 3.0, the 
> [TriggerExecutor.execute(PartitionUpdate)|https://github.com/jasonstack/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/triggers/TriggerExecutor.java#L82-L89]
>  will only return augmented mutation, ignoring original update..
> [Test|https://github.com/jasonstack/cassandra/commit/eb28844035242c4cb73c5148254f34672f2325da]to
>  reproduce.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13894) TriggerExecutor ignored original PartitionUpdate

[ZhaoYang (JIRA)]

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

ZhaoYang edited comment on CASSANDRA-13894 at 9/22/17 9:28 AM:
---

| source |
| 
[trunk|https://github.com/jasonstack/cassandra/commits/trigger-missing-update] |
| 
[3.11|https://github.com/jasonstack/cassandra/commits/trigger-missing-update-3.11]
 |
| 
[3.0|https://github.com/jasonstack/cassandra/commits/trigger-missing-update-3.0]
 |

CI is running.

changes:  concatenate original PartitionUpdate with augmented updates.


was (Author: jasonstack):
| source |
| 
[trunk|https://github.com/jasonstack/cassandra/commits/trigger-missing-update] |
| 
[3.11|https://github.com/jasonstack/cassandra/commits/trigger-missing-update-3.11]
 |
| 
[3.0|https://github.com/jasonstack/cassandra/commits/trigger-missing-update-3.0]
 |

changes:  concatenate original PartitionUpdate with augmented updates.

> TriggerExecutor ignored original PartitionUpdate
> 
>
> Key: CASSANDRA-13894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13894
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: ZhaoYang
>Assignee: ZhaoYang
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Since 3.0, the 
> [TriggerExecutor.execute(PartitionUpdate)|https://github.com/jasonstack/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/triggers/TriggerExecutor.java#L82-L89]
>  will only return augmented mutation, ignoring original update..
> [Test|https://github.com/jasonstack/cassandra/commit/eb28844035242c4cb73c5148254f34672f2325da]to
>  reproduce.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-13404:


We already have a plugable interface for authentication: IAuthenticator. But 
it's working on the application layer, i.e. the tls connection will already be 
established at this point. 

The IAuthenticator interface and the SASL based negotiation process is pretty 
flexible though. You can already create and use your own implementation that 
would validate any provided certificate as you see fit. But then you'd also 
have to implement this on the client side as well and I'm not sure if that 
would be possible for you.

> Hostname verification for client-to-node encryption
> ---
>
> Key: CASSANDRA-13404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13404
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jan Karlsson
>Assignee: Jan Karlsson
> Fix For: 4.x
>
> Attachments: 13404-trunk.txt
>
>
> Similarily to CASSANDRA-9220, Cassandra should support hostname verification 
> for client-node connections.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13149) AssertionError prepending to a list

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-13149:
-

The batching logic in {{Prepender}} isn't quite right, in the huge list test 
for e.g. it winds up creating only 1 PT and the nanos used for the UUID end up 
going negative. I've pushed an alternative version 
[here|https://github.com/beobal/cassandra/commit/3e96a523d5c7e4692e7f743c65d725e2f893ab5f],
 lmk what you think. 

re: the over-engineering, yes I think you're probably right. I was thinking 
ahead, based on [~slebresne]'s suggestion that we could start using PT more 
widely, but let's leave it until that happens, perhaps YAGNI.



> AssertionError prepending to a list
> ---
>
> Key: CASSANDRA-13149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13149
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: 3.0.8
>Reporter: Steven Warren
>Assignee: Jason Brown
>
> Prepending to a list produces the following AssertionError randomly. Changing 
> the update to append (and sort in the client) works around the issue.
> {code}
> java.lang.AssertionError: null
>   at 
> org.apache.cassandra.cql3.Lists$PrecisionTime.getNext(Lists.java:275) 
> ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at org.apache.cassandra.cql3.Lists$Prepender.execute(Lists.java:430) 
> ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.cql3.statements.UpdateStatement.addUpdateForKey(UpdateStatement.java:94)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:682)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:613)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:420)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:408)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
>  [apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
>  [apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_101]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.8.jar:3.0.8]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.8.jar:3.0.8]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13894) TriggerExecutor ignored original PartitionUpdate

[ZhaoYang (JIRA)]

ZhaoYang created CASSANDRA-13894:


 Summary: TriggerExecutor ignored original PartitionUpdate
 Key: CASSANDRA-13894
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13894
 Project: Cassandra
  Issue Type: Bug
  Components: Local Write-Read Paths
Reporter: ZhaoYang
Assignee: ZhaoYang
 Fix For: 3.0.x, 3.11.x, 4.x


Since 3.0, the 
[TriggerExecutor.execute(PartitionUpdate)|https://github.com/jasonstack/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/triggers/TriggerExecutor.java#L82-L89]
 will only return augmented mutation, ignoring original update..

[Test|https://github.com/jasonstack/cassandra/commit/eb28844035242c4cb73c5148254f34672f2325da]to
 reproduce.






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13892) Make BTree.Builder use the initialCapacity

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson edited comment on CASSANDRA-13892 at 9/22/17 8:51 AM:
--

uh that failed miserably, (https://circleci.com/gh/krummas/cassandra/114) will 
make sure BTree.Builder handles initialCapacity = 0


was (Author: krummas):
uh that failed miserably, (https://circleci.com/gh/krummas/cassandra/114) will 
check that they have sane initialCapacities

> Make BTree.Builder use the initialCapacity
> --
>
> Key: CASSANDRA-13892
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13892
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> The initialCapacity passed to {{BTree.builder(comparator, initialCapacity)}} 
> is unused, start using it



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13893) Column name "AGE" is being created as "414745" (ASCII values)

[karthik (JIRA)]

karthik created CASSANDRA-13893:
---

 Summary: Column name "AGE" is being created as "414745" (ASCII 
values)
 Key: CASSANDRA-13893
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13893
 Project: Cassandra
  Issue Type: Bug
 Environment: Ubuntu 14
Reporter: karthik
Priority: Critical
 Fix For: 3.11.0


Command: 
{code:java}
CREATE TABLE test (id text, "AGE" text, primary key(id));
{code}


Result for DESCRIBE TABLE test:


{code:java}
CREATE TABLE "myKeyspace".test (
id text PRIMARY KEY,
"414745" text
) WITH bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{code}





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13892) Make BTree.Builder use the initialCapacity

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-13892:

Status: Open  (was: Patch Available)

uh that failed miserably, (https://circleci.com/gh/krummas/cassandra/114) will 
check that they have sane initialCapacities

> Make BTree.Builder use the initialCapacity
> --
>
> Key: CASSANDRA-13892
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13892
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> The initialCapacity passed to {{BTree.builder(comparator, initialCapacity)}} 
> is unused, start using it



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13892) Make BTree.Builder use the initialCapacity

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-13892:

Assignee: Marcus Eriksson
  Status: Patch Available  (was: Open)

https://github.com/krummas/cassandra/commits/marcuse/13892

dtests:
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/333/

> Make BTree.Builder use the initialCapacity
> --
>
> Key: CASSANDRA-13892
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13892
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> The initialCapacity passed to {{BTree.builder(comparator, initialCapacity)}} 
> is unused, start using it



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13892) Make BTree.Builder use the initialCapacity

[Marcus Eriksson (JIRA)]

Marcus Eriksson created CASSANDRA-13892:
---

 Summary: Make BTree.Builder use the initialCapacity
 Key: CASSANDRA-13892
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13892
 Project: Cassandra
  Issue Type: Bug
Reporter: Marcus Eriksson
 Fix For: 3.0.x, 3.11.x, 4.x


The initialCapacity passed to {{BTree.builder(comparator, initialCapacity)}} is 
unused, start using it



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (CASSANDRA-9783) 2.1-offheap compaction dtests fail

[Robert Stupp (JIRA)]

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

Robert Stupp resolved CASSANDRA-9783.
-
Resolution: Not A Problem

Yea, good to close this one.
Off-heap dtests don't look worse than normal dtests now.

> 2.1-offheap compaction dtests fail
> --
>
> Key: CASSANDRA-9783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9783
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>
> All compaction dtests fail because the generated files are too large 
> (assertion failure). See 
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/117/testReport/
> The tests work fine in non-offheap configuration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (CASSANDRA-10659) Windows CassCI: Fail on timed-out tests

[Philip Thompson (JIRA)]

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

Philip Thompson resolved CASSANDRA-10659.
-
Resolution: Won't Fix

> Windows CassCI: Fail on timed-out tests
> ---
>
> Key: CASSANDRA-10659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10659
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Jim Witschey
>
> On our Windows CassCI environments, it looks like some dtests are prone to 
> hanging, e.g.:
> https://cassci.datastax.com/view/Dev/view/josh-mckenzie/job/josh-mckenzie-10641_windows-dtest_win32/1/
> http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest_win32/131/
> http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest_win32/129/
> http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest_win32/128/
> http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest_win32/126/
> http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest_win32/125/
> Ideally these tests wouldn't hang, but regardless, we should figure out a way 
> to make them fail, rather than timing out Jenkins and botching the rest of 
> the test run.
> The built-in [{{nosetests}} {{multiprocess}} 
> plugin|http://nose.readthedocs.org/en/latest/plugins/multiprocess.html] would 
> solve this problem for us -- we could run the tests with {{nosetests 
> --processes=1 --process-timeout=X}} and it would stop the test and fail if 
> the test took too long. However, it's broken on Windows. I've filed [a quick 
> issue on the {{nose}} GitHub|https://github.com/nose-devs/nose/issues/966], 
> but in the meantime, we should figure out how to avoid this.
> Possible solutions:
> # [~philipthompson] had a script that would shell out to {{nosetests}} for 
> each test and kill that process if it took too long. If I understand 
> correctly, that script is broken, or assumes things that are no longer true. 
> We can revamp it if we want.
> # We could make a patch for {{nose}} to fix the {{multiprocess}} plugin.
> # We could hack in some of {{multiprocessing}}'s functionality into the 
> {{dtest}} suite itself.
> 3. may be the best workaround for this problem -- our timeouts aren't caused 
> just when a tests runs long, but when Jenkins doesn't get any output on 
> stdout from a hanging test. We may be able to monitor stdout from a second 
> process and fail the test before Jenkins would time out.
> Pinging [~JoshuaMcKenzie] as this is a Windows issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13404:


Before we jump into the code, I'd like to see some consensus among committers. 
[~spo...@gmail.com], what do you think about a pluggable interface that would 
allow these folks to extend client auth to support a feature like this? I have 
to admit I haven't read the code, and I don't know if there's a natural 
extension point, but are you ok with it in theory (it sounds like Jason is ok 
with it in theory)? 



> Hostname verification for client-to-node encryption
> ---
>
> Key: CASSANDRA-13404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13404
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jan Karlsson
>Assignee: Jan Karlsson
> Fix For: 4.x
>
> Attachments: 13404-trunk.txt
>
>
> Similarily to CASSANDRA-9220, Cassandra should support hostname verification 
> for client-node connections.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption

[JIRA]

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

Per Otterström commented on CASSANDRA-13404:


That is an interesting approach. A bit overkill for this small change in 
itself. And if we argue that the "require_endpoint_verification" option easily 
could get misunderstood or misconfigured, then I think this will present far 
more opportunities to get it wrong.

Then again, making this pluggable would be very powerful and I can think of a 
few useful ways to use that. On the downside, this approach will not encourage 
users to provide security improvements to the community, but instead keep that 
in their own custom plugins.

I'm willing to work out an example on how such a plugin API could look. Unless 
someone else was planning to grab this task of course?

> Hostname verification for client-to-node encryption
> ---
>
> Key: CASSANDRA-13404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13404
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jan Karlsson
>Assignee: Jan Karlsson
> Fix For: 4.x
>
> Attachments: 13404-trunk.txt
>
>
> Similarily to CASSANDRA-9220, Cassandra should support hostname verification 
> for client-node connections.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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