[jira] [Created] (CASSANDRA-13862) Optimize Paxos prepare and propose stage for local requests

[Jaydeepkumar Chovatia (JIRA)]

Jaydeepkumar Chovatia created CASSANDRA-13862:
-

 Summary: Optimize Paxos prepare and propose stage for local 
requests 
 Key: CASSANDRA-13862
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13862
 Project: Cassandra
  Issue Type: Improvement
  Components: Streaming and Messaging
Reporter: Jaydeepkumar Chovatia
Priority: Minor
 Fix For: 3.0.15


Currently Paxos prepare and propose messages always go through entire 
MessagingService stack in Cassandra even if request is to be served locally, we 
can enhance and make local requests severed w/o involving MessagingService. 
Similar things are done at may [other places | 
https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageProxy.java#L1244]
 in Cassandra which skips MessagingService stage for local requests.


This is what it looks like currently if we have tracing on and run Cassandra 
light weight transaction.

{{
…   
 
Sending PAXOS_PREPARE message to /A.B.C.D [MessagingService-Outgoing-/A.B.C.D] 
| 2017-09-11 21:55:18.971000 |  A.B.C.D |  15045
…   
   
REQUEST_RESPONSE message received from /A.B.C.D 
[MessagingService-Incoming-/A.B.C.D] | 2017-09-11 21:55:18.976000 |  A.B.C.D |  
20270
…   

 Processing response from /A.B.C.D [SharedPool-Worker-4] | 
2017-09-11 21:55:18.976000 |  A.B.C.D |  20372
…
}}

Same thing applies for Propose stage as well.





--
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-13760) presize collections

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa edited comment on CASSANDRA-13760 at 9/12/17 4:10 AM:
-

Just realized that those are both fixed by 
{{e1aa7d32c95ff3f06de97803a186ff432237ecab}}, which isn't in (y)our branch, so 
I've rebased and 
[force-pushed|https://github.com/jeffjirsa/cassandra/commits/cassandra-13760]. 
The new dtest will be @ 
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/301/




was (Author: jjirsa):
Just realized that those are both fixed by 
{{e1aa7d32c95ff3f06de97803a186ff432237ecab}}, which isn't in (y)our branch, so 
I've rebased and 
[force-pushed|https://github.com/jeffjirsa/cassandra/commits/cassandra-13760]. 
The new dtest will be @ 
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/283/
 



> presize collections
> ---
>
> Key: CASSANDRA-13760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13760
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Dave Brosius
>Assignee: Dave Brosius
>Priority: Trivial
> Fix For: 4.x
>
> Attachments: 0001-Presize-collections.patch, 13760.txt, 
> test-output.png
>
>
> presize collections where sane, to avoid reallocs, or excess garbage



--
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-13069) Local batchlog for MV may not be correctly written on node movements

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-13069:
-

Thanks for the review!

bq. But this is admittedly not the place to debate about this, and you are 
right that things aren't as grim as I portrayed it in my previous comment 
anyway, so happy to focus on just the bug for which this was opened for.

+1

bq. My understanding is that the main goal of the batchlog delay is to avoid 
replaying batches that may still have a change to succeed, but your change 
seems to break that, so it sounds like that could have adverse performance 
effect, including on non-view usages of the batchlog.

Agreed, I was not very happy with this either, thanks for noting. The main 
reason was to ensure the view batchlog would be replayed on startup, to be able 
to test that properly, but I was able to achieve the same effect by [exposing 
the batchlog 
timeout|https://github.com/apache/cassandra/commit/a3672d5bb825a53c732e9534073c4e1ea729dedd]
 via a {{-Dcassandra.batchlog.replay_timeout_in_ms}} property, which [is set 
during 
dtest|https://github.com/apache/cassandra-dtest/compare/master...pauloricardomg:13069#diff-62ba429edee6a4681782f078246c9893R1943]
 and waited before replay. 

In practice, this means the user will still need to wait 
{{cassandra.batchlog.replay_timeout_in_ms=2*write_request_timeout_in_ms}} to 
ensure its failed views will be properly applied after a node is restartated, 
but since this is 4s by default it should be acceptable.

Resubmitted CI with the above change. Please let me know what do you think.

> Local batchlog for MV may not be correctly written on node movements
> 
>
> Key: CASSANDRA-13069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13069
> Project: Cassandra
>  Issue Type: Bug
>  Components: Materialized Views
>Reporter: Sylvain Lebresne
>Assignee: Paulo Motta
>
> Unless I'm really reading this wrong, I think the code 
> [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageProxy.java#L829-L843],
>  which comes from CASSANDRA-10674, isn't working properly.
> More precisely, I believe we can have both paired and unpaired mutations, so 
> that both {{if}} can be taken, but if that's the case, the 2nd write to the 
> batchlog will basically overwrite (remove) the batchlog write of the 1st 
> {{if}} and I don't think that's the intention. In practice, this means 
> "paired" mutation won't be in the batchlog, which mean they won't be replayed 
> at all if they fail.



--
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-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13717:
-

backported the patch to 3.0 and 3.11, and running tests now:

||3.0||3.11||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/13717-3.0]|[branch|https://github.com/jasobrown/cassandra/tree/13717-3.11]|[branch|https://github.com/jasobrown/cassandra/tree/13717-trunk]|
|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/298/]|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/299/]|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/300/]|
|[utests|https://circleci.com/gh/jasobrown/cassandra/tree/13717-3.0]|[utests|https://circleci.com/gh/jasobrown/cassandra/tree/13717-3.11]|[utests|https://circleci.com/gh/jasobrown/cassandra/tree/13717-trunk]|


> INSERT statement fails when Tuple type is used as clustering column with 
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
>Assignee: Stavros Kontopoulos
>Priority: Critical
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: example_queries.cql, fix_13717
>
>
> When a column family is created and a Tuple is used on clustering column with 
> default clustering order DESC, then the INSERT statement fails. 
> For example, the following table will make the INSERT statement fail with 
> error message "Invalid tuple type literal for tdemo of type 
> frozen>" , although the INSERT statement is correct 
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
>   id int,
>   tdemo tuple,
>   primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}



--
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-13846) Add additional unit tests for batch behavior, TTLs, Timestamps

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13846:
---
   Resolution: Fixed
Fix Version/s: (was: 4.x)
   4.0
   Status: Resolved  (was: Ready to Commit)

Thanks. Committed to trunk only as {{471835815811d4de42474a3e3899a42cb6d969ce}}


> Add additional unit tests for batch behavior, TTLs, Timestamps
> --
>
> Key: CASSANDRA-13846
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13846
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
> Fix For: 4.0
>
>
> There are some combinations of batch behavior for which there are no unit 
> tests. An example of this is CASSANDRA-13655 , which adds some tests, but not 
> every combination. This ticket will be for additional unit tests around 
> batches / counter batches / batches with TTLs / etc.



--
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-13846) Add additional unit tests for batch behavior, TTLs, Timestamps

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13846:
---
Status: Ready to Commit  (was: Patch Available)

> Add additional unit tests for batch behavior, TTLs, Timestamps
> --
>
> Key: CASSANDRA-13846
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13846
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
> Fix For: 4.0
>
>
> There are some combinations of batch behavior for which there are no unit 
> tests. An example of this is CASSANDRA-13655 , which adds some tests, but not 
> every combination. This ticket will be for additional unit tests around 
> batches / counter batches / batches with TTLs / etc.



--
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-13786) Validation compactions can cause orphan sstable warnings

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-13786:
-

rebased on latest trunk: 
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/297/]

> Validation compactions can cause orphan sstable warnings
> 
>
> Key: CASSANDRA-13786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13786
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 4.0
>
>
> I've seen LevelledCompactionStrategy occasionally logging: 
> {quote} from level 0 is not on corresponding level in the 
> leveled manifest. This is not a problem per se, but may indicate an orphaned 
> sstable due to a failed compaction not cleaned up properly."{quote} warnings 
> from a ValidationExecutor thread.
> What's happening here is that a compaction running concurrently with the 
> validation is promoting (or demoting) sstables as part of an incremental 
> repair, and an sstable has changed hands by the time the validation 
> compaction gets around to getting scanners for it. The sstable 
> isolation/synchronization done by validation compactions is a lot looser than 
> normal compactions, so seeing this happen isn't very surprising. Given that 
> it's harmless, and not unexpected, I think it would be best to not log these 
> during validation compactions.



--
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

cassandra git commit: Add additional unit tests for batch behavior, TTLs, Timestamps

[jjirsa]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 795c1f36e -> 471835815


Add additional unit tests for batch behavior, TTLs, Timestamps

Patch by Jeff Jirsa; Reviewed by Jason Brown for CASSANDRA-13846


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

Branch: refs/heads/trunk
Commit: 471835815811d4de42474a3e3899a42cb6d969ce
Parents: 795c1f3
Author: Jeff Jirsa 
Authored: Sun Jul 9 16:16:29 2017 -0700
Committer: Jeff Jirsa 
Committed: Mon Sep 11 15:59:44 2017 -0700

--
 CHANGES.txt |   1 +
 .../apache/cassandra/batchlog/BatchTest.java| 107 ---
 .../apache/cassandra/batchlog/BatchlogTest.java | 107 +++
 .../cql3/validation/entities/CountersTest.java  |  68 
 .../cql3/validation/entities/TimestampTest.java |  37 +++
 .../cql3/validation/operations/BatchTest.java   | 320 ++-
 6 files changed, 528 insertions(+), 112 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/47183581/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5e9cb72..c688d6d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Add additional unit tests for batch behavior, TTLs, Timestamps 
(CASSANDRA-13846)
  * Add keyspace and table name in schema validation exception (CASSANDRA-13845)
  * Emit metrics whenever we hit tombstone failures and warn thresholds 
(CASSANDRA-13771)
  * Make netty EventLoopGroups daemon threads (CASSANDRA-13837)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/47183581/test/unit/org/apache/cassandra/batchlog/BatchTest.java
--
diff --git a/test/unit/org/apache/cassandra/batchlog/BatchTest.java 
b/test/unit/org/apache/cassandra/batchlog/BatchTest.java
deleted file mode 100644
index 8ed1811..000
--- a/test/unit/org/apache/cassandra/batchlog/BatchTest.java
+++ /dev/null
@@ -1,107 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements.  See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership.  The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License.  You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.cassandra.batchlog;
-
-import java.io.IOException;
-import java.nio.ByteBuffer;
-import java.util.ArrayList;
-import java.util.Iterator;
-import java.util.List;
-import java.util.UUID;
-
-import org.junit.BeforeClass;
-import org.junit.Test;
-
-import org.apache.cassandra.SchemaLoader;
-import org.apache.cassandra.schema.TableMetadata;
-import org.apache.cassandra.db.Keyspace;
-import org.apache.cassandra.db.Mutation;
-import org.apache.cassandra.db.RowUpdateBuilder;
-import org.apache.cassandra.db.marshal.BytesType;
-import org.apache.cassandra.exceptions.ConfigurationException;
-import org.apache.cassandra.io.util.DataInputBuffer;
-import org.apache.cassandra.io.util.DataInputPlus;
-import org.apache.cassandra.io.util.DataOutputBuffer;
-import org.apache.cassandra.net.MessagingService;
-import org.apache.cassandra.schema.KeyspaceParams;
-import org.apache.cassandra.utils.FBUtilities;
-import org.apache.cassandra.utils.UUIDGen;
-
-import static org.apache.cassandra.utils.ByteBufferUtil.bytes;
-import static org.junit.Assert.assertEquals;
-
-public class BatchTest
-{
-private static final String KEYSPACE = "BatchRequestTest";
-private static final String CF_STANDARD = "Standard";
-
-@BeforeClass
-public static void defineSchema() throws ConfigurationException
-{
-SchemaLoader.prepareServer();
-SchemaLoader.createKeyspace(KEYSPACE,
-KeyspaceParams.simple(1),
-SchemaLoader.standardCFMD(KEYSPACE, 
CF_STANDARD, 1, BytesType.instance));
-}
-
-@Test
-public void testSerialization() throws IOException
-{
-TableMetadata cfm = 
Keyspace.open(KEYSPACE).getColumnFamilyStore(CF_STANDARD).metadata();
-
-long now = 

[jira] [Commented] (CASSANDRA-13818) Add support for --hosts, --force, and subrange repair to incremental repair

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-13818:
-

rebased on latest trunk: 
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/296/]

> Add support for --hosts, --force, and subrange repair to incremental repair
> ---
>
> Key: CASSANDRA-13818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13818
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> It should be possible to run incremental repair with nodes down, we just 
> shouldn't promote the data to repaired afterwards



--
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-13797) RepairJob blocks on syncTasks

[Blake Eggleston (JIRA)]

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

Blake Eggleston edited comment on CASSANDRA-13797 at 9/11/17 10:55 PM:
---

rebased on latest trunk: 
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/295/]


was (Author: bdeggleston):
rebased on latest trunk: 
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/

> RepairJob blocks on syncTasks
> -
>
> Key: CASSANDRA-13797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13797
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> The thread running {{RepairJob}} blocks while it waits for the validations it 
> starts to complete ([see 
> here|https://github.com/bdeggleston/cassandra/blob/9fdec0a82851f5c35cd21d02e8c4da8fc685edb2/src/java/org/apache/cassandra/repair/RepairJob.java#L185]).
>  However, the downstream callbacks (ie: the post-repair cleanup stuff) aren't 
> waiting for {{RepairJob#run}} to return, they're waiting for a result to be 
> set on RepairJob the future, which happens after the sync tasks have 
> completed. This post repair cleanup stuff also immediately shuts down the 
> executor {{RepairJob#run}} is running in. So in noop repair sessions, where 
> there's nothing to stream, I'm seeing the callbacks sometimes fire before 
> {{RepairJob#run}} wakes up, and causing an {{InterruptedException}} is thrown.
> I'm pretty sure this can just be removed, but I'd like a second opinion. This 
> appears to just be a holdover from before repair coordination became async. I 
> thought it might be doing some throttling by blocking, but each repair 
> session gets it's own executor, and validation is  throttled by the fixed 
> size executors doing the actual work of validation, so I don't think we need 
> to keep this around.



--
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-13797) RepairJob blocks on syncTasks

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-13797:
-

rebased on latest trunk: 
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/

> RepairJob blocks on syncTasks
> -
>
> Key: CASSANDRA-13797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13797
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> The thread running {{RepairJob}} blocks while it waits for the validations it 
> starts to complete ([see 
> here|https://github.com/bdeggleston/cassandra/blob/9fdec0a82851f5c35cd21d02e8c4da8fc685edb2/src/java/org/apache/cassandra/repair/RepairJob.java#L185]).
>  However, the downstream callbacks (ie: the post-repair cleanup stuff) aren't 
> waiting for {{RepairJob#run}} to return, they're waiting for a result to be 
> set on RepairJob the future, which happens after the sync tasks have 
> completed. This post repair cleanup stuff also immediately shuts down the 
> executor {{RepairJob#run}} is running in. So in noop repair sessions, where 
> there's nothing to stream, I'm seeing the callbacks sometimes fire before 
> {{RepairJob#run}} wakes up, and causing an {{InterruptedException}} is thrown.
> I'm pretty sure this can just be removed, but I'd like a second opinion. This 
> appears to just be a holdover from before repair coordination became async. I 
> thought it might be doing some throttling by blocking, but each repair 
> session gets it's own executor, and validation is  throttled by the fixed 
> size executors doing the actual work of validation, so I don't think we need 
> to keep this around.



--
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-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13717:

Fix Version/s: 4.x
   3.11.x
   3.0.x

> INSERT statement fails when Tuple type is used as clustering column with 
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
>Assignee: Stavros Kontopoulos
>Priority: Critical
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: example_queries.cql, fix_13717
>
>
> When a column family is created and a Tuple is used on clustering column with 
> default clustering order DESC, then the INSERT statement fails. 
> For example, the following table will make the INSERT statement fail with 
> error message "Invalid tuple type literal for tdemo of type 
> frozen>" , although the INSERT statement is correct 
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
>   id int,
>   tdemo tuple,
>   primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}



--
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-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13717:
-

This bug exists in 3.0, as well - perhaps earlier, but even if it does this 
doesn't meet the bar of being 'critical' to patch 2.x for.

> INSERT statement fails when Tuple type is used as clustering column with 
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
>Assignee: Stavros Kontopoulos
>Priority: Critical
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: example_queries.cql, fix_13717
>
>
> When a column family is created and a Tuple is used on clustering column with 
> default clustering order DESC, then the INSERT statement fails. 
> For example, the following table will make the INSERT statement fail with 
> error message "Invalid tuple type literal for tdemo of type 
> frozen>" , although the INSERT statement is correct 
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
>   id int,
>   tdemo tuple,
>   primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}



--
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-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13717:

Reviewer: Jason Brown

> INSERT statement fails when Tuple type is used as clustering column with 
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
>Assignee: Stavros Kontopoulos
>Priority: Critical
> Attachments: example_queries.cql, fix_13717
>
>
> When a column family is created and a Tuple is used on clustering column with 
> default clustering order DESC, then the INSERT statement fails. 
> For example, the following table will make the INSERT statement fail with 
> error message "Invalid tuple type literal for tdemo of type 
> frozen>" , although the INSERT statement is correct 
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
>   id int,
>   tdemo tuple,
>   primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}



--
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-13754) BTree.Builder memory leak

[Eric Evans (JIRA)]

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

Eric Evans updated CASSANDRA-13754:
---
Attachment: Screenshot from 2017-09-11 16-54-43.png

> BTree.Builder memory leak
> -
>
> Key: CASSANDRA-13754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13754
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 3.11.0, Netty 4.0.44.Final, OpenJDK 8u141-b15
>Reporter: Eric Evans
>Assignee: Robert Stupp
> Fix For: 3.11.1
>
> Attachments: Screenshot from 2017-09-11 16-54-43.png
>
>
> After a chronic bout of {{OutOfMemoryError}} in our development environment, 
> a heap analysis is showing that more than 10G of our 12G heaps are consumed 
> by the {{threadLocals}} members (instances of {{java.lang.ThreadLocalMap}}) 
> of various {{io.netty.util.concurrent.FastThreadLocalThread}} instances.  
> Reverting 
> [cecbe17|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=cecbe17e3eafc052acc13950494f7dddf026aa54]
>  fixes the 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] [Reopened] (CASSANDRA-13754) BTree.Builder memory leak

[Eric Evans (JIRA)]

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

Eric Evans reopened CASSANDRA-13754:


I apologize for chiming in here so late, but I'm not sure this addresses what I 
was seeing.  In my dumps, all of the heap is tied up in the {{ThreadLocalMap}} 
s of instances of {{FastThreadLocalThread}} for _Native-Transport-Requests_, 
_RequestResponseStage_, _ReadStage_, etc; I think what I was seeing is 
different than [~markusdlugi].

See the attached screenshot of the dominator tree view in MemoryAnalyzer.

I can make a dump available, but be warned, it is 12G in size.

> BTree.Builder memory leak
> -
>
> Key: CASSANDRA-13754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13754
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 3.11.0, Netty 4.0.44.Final, OpenJDK 8u141-b15
>Reporter: Eric Evans
>Assignee: Robert Stupp
> Fix For: 3.11.1
>
>
> After a chronic bout of {{OutOfMemoryError}} in our development environment, 
> a heap analysis is showing that more than 10G of our 12G heaps are consumed 
> by the {{threadLocals}} members (instances of {{java.lang.ThreadLocalMap}}) 
> of various {{io.netty.util.concurrent.FastThreadLocalThread}} instances.  
> Reverting 
> [cecbe17|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=cecbe17e3eafc052acc13950494f7dddf026aa54]
>  fixes the 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

[03/15] cassandra git commit: Add 2.1.19 release to debian/changelog

[mshuler]

Add 2.1.19 release to debian/changelog


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

Branch: refs/heads/trunk
Commit: 665f69370a97470962b4442c42644fd99e42
Parents: fc38c38
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:06 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:06 2017 -0500

--
 debian/changelog | 6 ++
 1 file changed, 6 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/665f6937/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index a0ee850..64ab954 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (2.1.19) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 11 Sep 2017 16:49:58 -0500
+
 cassandra (2.1.18) unstable; urgency=medium
 
   * New release


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

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

[mshuler]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: e86bef4394650dfb96a041533de50c4fbf47bbdb
Parents: 433f24c 717dbe7
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:32 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:32 2017 -0500

--

--



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

[13/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[mshuler]

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

Branch: refs/heads/cassandra-3.11
Commit: b64a4e4f6b7fc8e49b9c3e9da0063df99615fbb3
Parents: fadf2e8 e86bef4
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:55 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:55 2017 -0500

--

--



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

[01/15] cassandra git commit: Add 2.1.19 release to debian/changelog

[mshuler]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 fc38c3835 -> 665f69370
  refs/heads/cassandra-2.2 8715c889a -> 717dbe741
  refs/heads/cassandra-3.0 433f24cb0 -> e86bef439
  refs/heads/cassandra-3.11 fadf2e839 -> b64a4e4f6
  refs/heads/trunk 145d1a48f -> 795c1f36e


Add 2.1.19 release to debian/changelog


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

Branch: refs/heads/cassandra-2.1
Commit: 665f69370a97470962b4442c42644fd99e42
Parents: fc38c38
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:06 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:06 2017 -0500

--
 debian/changelog | 6 ++
 1 file changed, 6 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/665f6937/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index a0ee850..64ab954 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (2.1.19) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 11 Sep 2017 16:49:58 -0500
+
 cassandra (2.1.18) unstable; urgency=medium
 
   * New release


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

[05/15] cassandra git commit: Add 2.1.19 release to debian/changelog

[mshuler]

Add 2.1.19 release to debian/changelog


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

Branch: refs/heads/cassandra-3.11
Commit: 665f69370a97470962b4442c42644fd99e42
Parents: fc38c38
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:06 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:06 2017 -0500

--
 debian/changelog | 6 ++
 1 file changed, 6 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/665f6937/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index a0ee850..64ab954 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (2.1.19) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 11 Sep 2017 16:49:58 -0500
+
 cassandra (2.1.18) unstable; urgency=medium
 
   * New release


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

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

[mshuler]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/trunk
Commit: 717dbe741d0c0fcd417546a9244fce8c1ba730d1
Parents: 8715c88 665f693
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:21 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:21 2017 -0500

--

--



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

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

[mshuler]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: e86bef4394650dfb96a041533de50c4fbf47bbdb
Parents: 433f24c 717dbe7
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:32 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:32 2017 -0500

--

--



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

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

[mshuler]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.11
Commit: e86bef4394650dfb96a041533de50c4fbf47bbdb
Parents: 433f24c 717dbe7
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:32 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:32 2017 -0500

--

--



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

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

[mshuler]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-3.11
Commit: 717dbe741d0c0fcd417546a9244fce8c1ba730d1
Parents: 8715c88 665f693
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:21 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:21 2017 -0500

--

--



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

[02/15] cassandra git commit: Add 2.1.19 release to debian/changelog

[mshuler]

Add 2.1.19 release to debian/changelog


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

Branch: refs/heads/cassandra-2.2
Commit: 665f69370a97470962b4442c42644fd99e42
Parents: fc38c38
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:06 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:06 2017 -0500

--
 debian/changelog | 6 ++
 1 file changed, 6 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/665f6937/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index a0ee850..64ab954 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (2.1.19) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 11 Sep 2017 16:49:58 -0500
+
 cassandra (2.1.18) unstable; urgency=medium
 
   * New release


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

[14/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[mshuler]

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

Branch: refs/heads/trunk
Commit: b64a4e4f6b7fc8e49b9c3e9da0063df99615fbb3
Parents: fadf2e8 e86bef4
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:55 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:55 2017 -0500

--

--



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

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

[mshuler]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-3.0
Commit: 717dbe741d0c0fcd417546a9244fce8c1ba730d1
Parents: 8715c88 665f693
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:21 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:21 2017 -0500

--

--



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

[04/15] cassandra git commit: Add 2.1.19 release to debian/changelog

[mshuler]

Add 2.1.19 release to debian/changelog


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

Branch: refs/heads/cassandra-3.0
Commit: 665f69370a97470962b4442c42644fd99e42
Parents: fc38c38
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:06 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:06 2017 -0500

--
 debian/changelog | 6 ++
 1 file changed, 6 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/665f6937/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index a0ee850..64ab954 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (2.1.19) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 11 Sep 2017 16:49:58 -0500
+
 cassandra (2.1.18) unstable; urgency=medium
 
   * New release


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

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

[mshuler]

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: 795c1f36ec10ccfdac36e2d33c757856f0ed33c5
Parents: 145d1a4 b64a4e4
Author: Michael Shuler 
Authored: Mon Sep 11 16:54:44 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:54:44 2017 -0500

--

--



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

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

[mshuler]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-2.2
Commit: 717dbe741d0c0fcd417546a9244fce8c1ba730d1
Parents: 8715c88 665f693
Author: Michael Shuler 
Authored: Mon Sep 11 16:53:21 2017 -0500
Committer: Michael Shuler 
Committed: Mon Sep 11 16:53:21 2017 -0500

--

--



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

[jira] [Commented] (CASSANDRA-13740) Orphan hint file gets created while node is being removed from cluster

[Jaydeepkumar Chovatia (JIRA)]

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

Jaydeepkumar Chovatia commented on CASSANDRA-13740:
---

Hi [~iamaleksey]

Can you please review my latest patch?

Jaydeep

> Orphan hint file gets created while node is being removed from cluster
> --
>
> Key: CASSANDRA-13740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13740
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Minor
> Fix For: 3.0.x, 3.11.x
>
> Attachments: 13740-3.0.15.txt, gossip_hang_test.py
>
>
> I have found this new issue during my test, whenever node is being removed 
> then hint file for that node gets written and stays inside the hint directory 
> forever. I debugged the code and found that it is due to the race condition 
> between [HintsWriteExecutor.java::flush | 
> https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/hints/HintsWriteExecutor.java#L195]
>  and [HintsWriteExecutor.java::closeWriter | 
> https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/hints/HintsWriteExecutor.java#L106]
> . 
>  
> *Time t1* Node is down, as a result Hints are being written by 
> [HintsWriteExecutor.java::flush | 
> https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/hints/HintsWriteExecutor.java#L195]
> *Time t2* Node is removed from cluster as a result it calls 
> [HintsService.java-exciseStore | 
> https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/hints/HintsService.java#L327]
>  which removes hint files for the node being removed
> *Time t3* Mutation stage keeps pumping Hints through [HintService.java::write 
> | 
> https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/hints/HintsService.java#L145]
>  which again calls [HintsWriteExecutor.java::flush | 
> https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/hints/HintsWriteExecutor.java#L215]
>  and new orphan file gets created
> I was writing a new dtest for {CASSANDRA-13562, CASSANDRA-13308} and that 
> helped me reproduce this new bug. I will submit patch for this new dtest 
> later.
> I also tried following to check how this orphan hint file responds:
> 1. I tried {{nodetool truncatehints }} but it fails as node is no 
> longer part of the ring
> 2. I then tried {{nodetool truncatehints}}, that still doesn’t remove hint 
> file because it is not yet included in the [dispatchDequeue | 
> https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/hints/HintsStore.java#L53]
> Reproducible steps:
> Please find dTest python file {{gossip_hang_test.py}} attached which 
> reproduces this bug.
> Solution:
> This is due to race condition as mentioned above. Since 
> {{HintsWriteExecutor.java}} creates thread pool with only 1 worker, so 
> solution becomes little simple. Whenever we [HintService.java::excise | 
> https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/hints/HintsService.java#L303]
>  a host, just store it in-memory, and check for already evicted host inside 
> [HintsWriteExecutor.java::flush | 
> https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/hints/HintsWriteExecutor.java#L215].
>  If already evicted host is found then ignore hints.
> Jaydeep



--
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-13846) Add additional unit tests for batch behavior, TTLs, Timestamps

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13846:
-

+1. 

> Add additional unit tests for batch behavior, TTLs, Timestamps
> --
>
> Key: CASSANDRA-13846
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13846
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
> Fix For: 4.x
>
>
> There are some combinations of batch behavior for which there are no unit 
> tests. An example of this is CASSANDRA-13655 , which adds some tests, but not 
> every combination. This ticket will be for additional unit tests around 
> batches / counter batches / batches with TTLs / etc.



--
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-13846) Add additional unit tests for batch behavior, TTLs, Timestamps

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13846:

Reviewer: Jason Brown

> Add additional unit tests for batch behavior, TTLs, Timestamps
> --
>
> Key: CASSANDRA-13846
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13846
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
> Fix For: 4.x
>
>
> There are some combinations of batch behavior for which there are no unit 
> tests. An example of this is CASSANDRA-13655 , which adds some tests, but not 
> every combination. This ticket will be for additional unit tests around 
> batches / counter batches / batches with TTLs / etc.



--
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-13846) Add additional unit tests for batch behavior, TTLs, Timestamps

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13846:
---
Status: Patch Available  (was: Open)

All code here is in {{test/}} , so not bothering with dtests 

Branch here: https://github.com/jeffjirsa/cassandra/tree/cassandra-13846
CircleCI: https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-13846


> Add additional unit tests for batch behavior, TTLs, Timestamps
> --
>
> Key: CASSANDRA-13846
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13846
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
> Fix For: 4.x
>
>
> There are some combinations of batch behavior for which there are no unit 
> tests. An example of this is CASSANDRA-13655 , which adds some tests, but not 
> every combination. This ticket will be for additional unit tests around 
> batches / counter batches / batches with TTLs / etc.



--
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-13846) Add additional unit tests for batch behavior, TTLs, Timestamps

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13846:
---
Summary: Add additional unit tests for batch behavior, TTLs, Timestamps  
(was: Add additional unit tests for batch behavior)

> Add additional unit tests for batch behavior, TTLs, Timestamps
> --
>
> Key: CASSANDRA-13846
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13846
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
> Fix For: 4.x
>
>
> There are some combinations of batch behavior for which there are no unit 
> tests. An example of this is CASSANDRA-13655 , which adds some tests, but not 
> every combination. This ticket will be for additional unit tests around 
> batches / counter batches / batches with TTLs / etc.



--
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-13780) ADD Node streaming throughput performance

[Kevin Rivait (JIRA)]

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

Kevin Rivait commented on CASSANDRA-13780:
--

Jason,we are looking forward to your streaming fix because it will better 
address our requirements to bootstrap new nodes as quickly as possible.  For 
the bootstrap node use case, assuming the code is efficiently implemented, 
being CPU bound for streaming is a good thing because it will minimize 
bootstrap time by maximizing node utilization, since during the bootstrap phase 
the node is not doing any query processing anyways,  right?  

> ADD Node streaming throughput performance
> -
>
> Key: CASSANDRA-13780
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13780
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
> Environment: Linux 2.6.32-696.3.2.el6.x86_64 #1 SMP Mon Jun 19 
> 11:55:55 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux
> Architecture:  x86_64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Little Endian
> CPU(s):40
> On-line CPU(s) list:   0-39
> Thread(s) per core:2
> Core(s) per socket:10
> Socket(s): 2
> NUMA node(s):  2
> Vendor ID: GenuineIntel
> CPU family:6
> Model: 79
> Model name:Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
> Stepping:  1
> CPU MHz:   2199.869
> BogoMIPS:  4399.36
> Virtualization:VT-x
> L1d cache: 32K
> L1i cache: 32K
> L2 cache:  256K
> L3 cache:  25600K
> NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38
> NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39
>  total   used   free sharedbuffers cached
> Mem:  252G   217G34G   708K   308M   149G
> -/+ buffers/cache:67G   185G
> Swap:  16G 0B16G
>Reporter: Kevin Rivait
> Fix For: 3.0.9
>
>
> Problem: Adding a new node to a large cluster runs at least 1000x slower than 
> what the network and node hardware capacity can support, taking several days 
> per new node.  Adjusting stream throughput and other YAML parameters seems to 
> have no effect on performance.  Essentially, it appears that Cassandra has an 
> architecture scalability growth problem when adding new nodes to a moderate 
> to high data ingestion cluster because Cassandra cannot add new node capacity 
> fast enough to keep up with increasing data ingestion volumes and growth.
> Initial Configuration: 
> Running 3.0.9 and have implemented TWCS on one of our largest table.
> Largest table partitioned on (ID, MM)  using 1 day buckets with a TTL of 
> 60 days.
> Next release will change partitioning to (ID, MMDD) so that partitions 
> are aligned with daily TWCS buckets.
> Each node is currently creating roughly a 30GB SSTable per day.
> TWCS working as expected,  daily SSTables are dropping off daily after 70 
> days ( 60 + 10 day grace)
> Current deployment is a 28 node 2 datacenter cluster, 14 nodes in each DC , 
> replication factor 3
> Data directories are backed with 4 - 2TB SSDs on each node  and a 1 800GB SSD 
> for commit logs.
> Requirement is to double cluster size, capacity, and ingestion volume within 
> a few weeks.
> Observed Behavior:
> 1. streaming throughput during add node – we observed maximum 6 Mb/s 
> streaming from each of the 14 nodes on a 20Gb/s switched network, taking at 
> least 106 hours for each node to join cluster and each node is only about 2.2 
> TB is size.
> 2. compaction on the newly added node - compaction has fallen behind, with 
> anywhere from 4,000 to 10,000 SSTables at any given time.  It took 3 weeks 
> for compaction to finish on each newly added node.   Increasing number of 
> compaction threads to match number of CPU (40)  and increasing compaction 
> throughput to 32MB/s seemed to be the sweet spot. 
> 3. TWCS buckets on new node, data streamed to this node over 4 1/2 days.  
> Compaction correctly placed the data in daily files, but the problem is the 
> file dates reflect when compaction created the file and not the date of the 
> last record written in the TWCS bucket, which will cause the files to remain 
> around much longer than necessary.  
> Two Questions:
> 1. What can be done to substantially improve the performance of adding a new 
> node?
> 2. Can compaction on TWCS partitions for newly added nodes change the file 
> create date to match the highest date record in the file -or- add another 
> piece of meta-data to the TWCS files that reflect the file drop date so that 
> TWCS partitions can be dropped consistently?



--
This message was 

[jira] [Updated] (CASSANDRA-13861) LCS ignores compaction thresholds in L0 STCS

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13861:
---
Fix Version/s: 4.x

> LCS ignores compaction thresholds in L0 STCS
> 
>
> Key: CASSANDRA-13861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13861
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
> Fix For: 4.x
>
>
> min max compaction thresholds are hard coded to 4 and 32



--
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-13861) LCS ignores compaction thresholds in L0 STCS

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13861:
---
Priority: Minor  (was: Major)

> LCS ignores compaction thresholds in L0 STCS
> 
>
> Key: CASSANDRA-13861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13861
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Minor
> Fix For: 4.x
>
>
> min max compaction thresholds are hard coded to 4 and 32



--
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-13861) LCS ignores compaction thresholds in L0 STCS

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13861:


+1 (for trunk only). 

We should be good citizens and run through circleci , just to be sure we don't 
have any surprises (I know it's a trivial patch, but wouldnt want to break the 
build or something with missing semicolon). Can you queue that up or do you 
need me to?


> LCS ignores compaction thresholds in L0 STCS
> 
>
> Key: CASSANDRA-13861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13861
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Minor
> Fix For: 4.x
>
>
> min max compaction thresholds are hard coded to 4 and 32



--
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-13655) Range deletes in a CAS batch are ignored

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13655:
---
   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: Ready to Commit)

Thank you both for your review (I've included both [~jay.zhuang] and 
[~slebresne] in the commit line, appreciate 2 sets of eyes).

Committed to 3.0 as {{433f24cb04dbcf74029a918ee73155f78d5f8111}} and merged up.


> Range deletes in a CAS batch are ignored
> 
>
> Key: CASSANDRA-13655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13655
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Blocker
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> Range deletes in a CAS batch are ignored 



--
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-13655) Range deletes in a CAS batch are ignored

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13655:
---
Status: Ready to Commit  (was: Patch Available)

> Range deletes in a CAS batch are ignored
> 
>
> Key: CASSANDRA-13655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13655
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Range deletes in a CAS batch are ignored 



--
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

[2/7] cassandra git commit: Range deletes in a CAS batch are ignored

[jjirsa]

Range deletes in a CAS batch are ignored

Patch by Jeff Jirsa; Reviewed by Jay Zhuang, Sylvain Lebresne for 
CASSANDRA-13655


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

Branch: refs/heads/cassandra-3.0
Commit: 433f24cb04dbcf74029a918ee73155f78d5f8111
Parents: ae88fd6
Author: Jeff Jirsa 
Authored: Mon Sep 11 09:35:01 2017 -0700
Committer: Jeff Jirsa 
Committed: Mon Sep 11 09:35:01 2017 -0700

--
 CHANGES.txt |   1 +
 .../cql3/statements/BatchStatement.java |  36 --
 .../cql3/statements/CQL3CasRequest.java |  31 ++
 .../cql3/statements/ModificationStatement.java  |  15 ++-
 .../org/apache/cassandra/cql3/BatchTests.java   |  51 +++--
 .../cql3/validation/operations/BatchTest.java   | 111 +++
 6 files changed, 219 insertions(+), 26 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/433f24cb/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f4360be..76d155e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.15
+ * Range deletes in a CAS batch are ignored (CASSANDRA-13655)
  * Change repair midpoint logging for tiny ranges (CASSANDRA-13603)
  * Better handle corrupt final commitlog segment (CASSANDRA-11995)
  * StreamingHistogram is not thread safe (CASSANDRA-13756)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/433f24cb/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
index 76a6460..cd9358c 100644
--- a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
@@ -417,18 +417,36 @@ public class BatchStatement implements CQLStatement
"IN on the clustering key columns is not supported with 
conditional %s",
statement.type.isUpdate()? "updates" : "deletions");
 
-Clustering clustering = 
Iterables.getOnlyElement(statement.createClustering(statementOptions));
+if (statement.hasSlices())
+{
+// All of the conditions require meaningful Clustering, not 
Slices
+assert !statement.hasConditions();
+
+Slices slices = statement.createSlices(statementOptions);
+// If all the ranges were invalid we do not need to do 
anything.
+if (slices.isEmpty())
+continue;
+
+for (Slice slice : slices)
+{
+casRequest.addRangeDeletion(slice, statement, 
statementOptions, timestamp);
+}
 
-if (statement.hasConditions())
+}
+else
 {
-statement.addConditions(clustering, casRequest, 
statementOptions);
-// As soon as we have a ifNotExists, we set 
columnsWithConditions to null so that everything is in the resultSet
-if (statement.hasIfNotExistCondition() || 
statement.hasIfExistCondition())
-columnsWithConditions = null;
-else if (columnsWithConditions != null)
-Iterables.addAll(columnsWithConditions, 
statement.getColumnsWithConditions());
+Clustering clustering = 
Iterables.getOnlyElement(statement.createClustering(statementOptions));
+if (statement.hasConditions())
+{
+statement.addConditions(clustering, casRequest, 
statementOptions);
+// As soon as we have a ifNotExists, we set 
columnsWithConditions to null so that everything is in the resultSet
+if (statement.hasIfNotExistCondition() || 
statement.hasIfExistCondition())
+columnsWithConditions = null;
+else if (columnsWithConditions != null)
+Iterables.addAll(columnsWithConditions, 
statement.getColumnsWithConditions());
+}
+casRequest.addRowUpdate(clustering, statement, 
statementOptions, timestamp);
 }
-casRequest.addRowUpdate(clustering, statement, statementOptions, 
timestamp);
 }
 
 return Pair.create(casRequest, columnsWithConditions);

[4/7] cassandra git commit: Range deletes in a CAS batch are ignored

[jjirsa]

Range deletes in a CAS batch are ignored

Patch by Jeff Jirsa; Reviewed by Jay Zhuang, Sylvain Lebresne for 
CASSANDRA-13655


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

Branch: refs/heads/cassandra-3.11
Commit: 433f24cb04dbcf74029a918ee73155f78d5f8111
Parents: ae88fd6
Author: Jeff Jirsa 
Authored: Mon Sep 11 09:35:01 2017 -0700
Committer: Jeff Jirsa 
Committed: Mon Sep 11 09:35:01 2017 -0700

--
 CHANGES.txt |   1 +
 .../cql3/statements/BatchStatement.java |  36 --
 .../cql3/statements/CQL3CasRequest.java |  31 ++
 .../cql3/statements/ModificationStatement.java  |  15 ++-
 .../org/apache/cassandra/cql3/BatchTests.java   |  51 +++--
 .../cql3/validation/operations/BatchTest.java   | 111 +++
 6 files changed, 219 insertions(+), 26 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/433f24cb/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f4360be..76d155e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.15
+ * Range deletes in a CAS batch are ignored (CASSANDRA-13655)
  * Change repair midpoint logging for tiny ranges (CASSANDRA-13603)
  * Better handle corrupt final commitlog segment (CASSANDRA-11995)
  * StreamingHistogram is not thread safe (CASSANDRA-13756)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/433f24cb/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
index 76a6460..cd9358c 100644
--- a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
@@ -417,18 +417,36 @@ public class BatchStatement implements CQLStatement
"IN on the clustering key columns is not supported with 
conditional %s",
statement.type.isUpdate()? "updates" : "deletions");
 
-Clustering clustering = 
Iterables.getOnlyElement(statement.createClustering(statementOptions));
+if (statement.hasSlices())
+{
+// All of the conditions require meaningful Clustering, not 
Slices
+assert !statement.hasConditions();
+
+Slices slices = statement.createSlices(statementOptions);
+// If all the ranges were invalid we do not need to do 
anything.
+if (slices.isEmpty())
+continue;
+
+for (Slice slice : slices)
+{
+casRequest.addRangeDeletion(slice, statement, 
statementOptions, timestamp);
+}
 
-if (statement.hasConditions())
+}
+else
 {
-statement.addConditions(clustering, casRequest, 
statementOptions);
-// As soon as we have a ifNotExists, we set 
columnsWithConditions to null so that everything is in the resultSet
-if (statement.hasIfNotExistCondition() || 
statement.hasIfExistCondition())
-columnsWithConditions = null;
-else if (columnsWithConditions != null)
-Iterables.addAll(columnsWithConditions, 
statement.getColumnsWithConditions());
+Clustering clustering = 
Iterables.getOnlyElement(statement.createClustering(statementOptions));
+if (statement.hasConditions())
+{
+statement.addConditions(clustering, casRequest, 
statementOptions);
+// As soon as we have a ifNotExists, we set 
columnsWithConditions to null so that everything is in the resultSet
+if (statement.hasIfNotExistCondition() || 
statement.hasIfExistCondition())
+columnsWithConditions = null;
+else if (columnsWithConditions != null)
+Iterables.addAll(columnsWithConditions, 
statement.getColumnsWithConditions());
+}
+casRequest.addRowUpdate(clustering, statement, 
statementOptions, timestamp);
 }
-casRequest.addRowUpdate(clustering, statement, statementOptions, 
timestamp);
 }
 
 return Pair.create(casRequest, columnsWithConditions);

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

[jjirsa]

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

Branch: refs/heads/cassandra-3.11
Commit: fadf2e8392bc41e75d475f9c6a141059c9480f6d
Parents: 0fdbcc3 433f24c
Author: Jeff Jirsa 
Authored: Mon Sep 11 09:35:58 2017 -0700
Committer: Jeff Jirsa 
Committed: Mon Sep 11 09:36:20 2017 -0700

--
 CHANGES.txt |   1 +
 .../cql3/statements/BatchStatement.java |  36 --
 .../cql3/statements/CQL3CasRequest.java |  32 ++
 .../cql3/statements/ModificationStatement.java  |  15 ++-
 .../org/apache/cassandra/cql3/BatchTests.java   |  51 +++--
 .../cql3/validation/operations/BatchTest.java   | 111 +++
 6 files changed, 220 insertions(+), 26 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fadf2e83/CHANGES.txt
--
diff --cc CHANGES.txt
index 23e6c8b,76d155e..52775e7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,15 -1,5 +1,16 @@@
 -3.0.15
 +3.11.1
 + * Add a compaction option to TWCS to ignore sstables overlapping checks 
(CASSANDRA-13418)
 + * BTree.Builder memory leak (CASSANDRA-13754)
 + * Revert CASSANDRA-10368 of supporting non-pk column filtering due to 
correctness (CASSANDRA-13798)
 + * Fix cassandra-stress hang issues when an error during cluster connection 
happens (CASSANDRA-12938)
 + * Better bootstrap failure message when blocked by (potential) range 
movement (CASSANDRA-13744)
 + * "ignore" option is ignored in sstableloader (CASSANDRA-13721)
 + * Deadlock in AbstractCommitLogSegmentManager (CASSANDRA-13652)
 + * Duplicate the buffer before passing it to analyser in SASI operation 
(CASSANDRA-13512)
 + * Properly evict pstmts from prepared statements cache (CASSANDRA-13641)
 +Merged from 3.0:
+  * Range deletes in a CAS batch are ignored (CASSANDRA-13655)
 + * Avoid assertion error when IndexSummary > 2G (CASSANDRA-12014)
   * Change repair midpoint logging for tiny ranges (CASSANDRA-13603)
   * Better handle corrupt final commitlog segment (CASSANDRA-11995)
   * StreamingHistogram is not thread safe (CASSANDRA-13756)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fadf2e83/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fadf2e83/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
--
diff --cc src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
index 5683af4,e14ae6c..47920a4
--- a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
@@@ -226,8 -232,14 +232,10 @@@ public class CQL3CasRequest implements 
  PartitionUpdate update = new PartitionUpdate(cfm, key, 
updatedColumns(), conditions.size());
  for (RowUpdate upd : updates)
  upd.applyUpdates(current, update);
+ for (RangeDeletion upd : rangeDeletions)
+ upd.applyUpdates(current, update);
  
  Keyspace.openAndGetStore(cfm).indexManager.validate(update);
 -
 -if (isBatch)
 -BatchStatement.verifyBatchSize(Collections.singleton(update));
 -
  return update;
  }
  
@@@ -260,6 -272,29 +268,30 @@@
  }
  }
  
+ private class RangeDeletion
+ {
+ private final Slice slice;
+ private final ModificationStatement stmt;
+ private final QueryOptions options;
+ private final long timestamp;
+ 
+ private RangeDeletion(Slice slice, ModificationStatement stmt, 
QueryOptions options, long timestamp)
+ {
+ this.slice = slice;
+ this.stmt = stmt;
+ this.options = options;
+ this.timestamp = timestamp;
+ }
+ 
+ public void applyUpdates(FilteredPartition current, PartitionUpdate 
updates) throws InvalidRequestException
+ {
++// No slice statements currently require a read, but this 
maintains consistency with RowUpdate, and future proofs us
+ Map map = stmt.requiresRead() ? 
Collections.singletonMap(key, current) : null;
+ UpdateParameters params = new UpdateParameters(cfm, 
updates.columns(), options, timestamp, stmt.getTimeToLive(options), map);
+ stmt.addUpdateForKey(updates, slice, params);
+ }
+ }
+ 
  private 

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

[jjirsa]

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

Branch: refs/heads/trunk
Commit: 145d1a48f6c1a98a9de2792c4a1a8d21653af0e6
Parents: 55d7017 fadf2e8
Author: Jeff Jirsa 
Authored: Mon Sep 11 09:36:30 2017 -0700
Committer: Jeff Jirsa 
Committed: Mon Sep 11 09:37:05 2017 -0700

--
 CHANGES.txt |   1 +
 .../cql3/statements/BatchStatement.java |  36 --
 .../cql3/statements/CQL3CasRequest.java |  32 ++
 .../cql3/statements/ModificationStatement.java  |  15 ++-
 .../org/apache/cassandra/cql3/BatchTests.java   |  51 +++--
 .../cql3/validation/operations/BatchTest.java   | 111 +++
 6 files changed, 220 insertions(+), 26 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/145d1a48/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/145d1a48/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/145d1a48/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
--
diff --cc src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
index c450160,47920a4..ec11df3
--- a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
@@@ -57,11 -56,12 +57,12 @@@ public class CQL3CasRequest implements 
  private final TreeMap conditions;
  
  private final List updates = new ArrayList<>();
+ private final List rangeDeletions = new ArrayList<>();
  
 -public CQL3CasRequest(CFMetaData cfm,
 +public CQL3CasRequest(TableMetadata metadata,
DecoratedKey key,
boolean isBatch,
 -  PartitionColumns conditionColumns,
 +  RegularAndStaticColumns conditionColumns,
boolean updatesRegularRows,
boolean updatesStaticRow)
  {
@@@ -229,11 -229,13 +235,13 @@@
  
  public PartitionUpdate makeUpdates(FilteredPartition current) throws 
InvalidRequestException
  {
 -PartitionUpdate update = new PartitionUpdate(cfm, key, 
updatedColumns(), conditions.size());
 +PartitionUpdate update = new PartitionUpdate(metadata, key, 
updatedColumns(), conditions.size());
  for (RowUpdate upd : updates)
  upd.applyUpdates(current, update);
+ for (RangeDeletion upd : rangeDeletions)
+ upd.applyUpdates(current, update);
  
 -Keyspace.openAndGetStore(cfm).indexManager.validate(update);
 +Keyspace.openAndGetStore(metadata).indexManager.validate(update);
  return update;
  }
  
@@@ -266,6 -268,30 +274,30 @@@
  }
  }
  
+ private class RangeDeletion
+ {
+ private final Slice slice;
+ private final ModificationStatement stmt;
+ private final QueryOptions options;
+ private final long timestamp;
+ 
+ private RangeDeletion(Slice slice, ModificationStatement stmt, 
QueryOptions options, long timestamp)
+ {
+ this.slice = slice;
+ this.stmt = stmt;
+ this.options = options;
+ this.timestamp = timestamp;
+ }
+ 
+ public void applyUpdates(FilteredPartition current, PartitionUpdate 
updates) throws InvalidRequestException
+ {
+ // No slice statements currently require a read, but this 
maintains consistency with RowUpdate, and future proofs us
+ Map map = stmt.requiresRead() ? 
Collections.singletonMap(key, current) : null;
 -UpdateParameters params = new UpdateParameters(cfm, 
updates.columns(), options, timestamp, stmt.getTimeToLive(options), map);
++UpdateParameters params = new UpdateParameters(metadata, 
updates.columns(), options, timestamp, stmt.getTimeToLive(options), map);
+ stmt.addUpdateForKey(updates, slice, params);
+ }
+ }
+ 
  private static abstract class RowCondition
  {
  public final Clustering clustering;

http://git-wip-us.apache.org/repos/asf/cassandra/blob/145d1a48/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java

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

[jjirsa]

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

Branch: refs/heads/trunk
Commit: fadf2e8392bc41e75d475f9c6a141059c9480f6d
Parents: 0fdbcc3 433f24c
Author: Jeff Jirsa 
Authored: Mon Sep 11 09:35:58 2017 -0700
Committer: Jeff Jirsa 
Committed: Mon Sep 11 09:36:20 2017 -0700

--
 CHANGES.txt |   1 +
 .../cql3/statements/BatchStatement.java |  36 --
 .../cql3/statements/CQL3CasRequest.java |  32 ++
 .../cql3/statements/ModificationStatement.java  |  15 ++-
 .../org/apache/cassandra/cql3/BatchTests.java   |  51 +++--
 .../cql3/validation/operations/BatchTest.java   | 111 +++
 6 files changed, 220 insertions(+), 26 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fadf2e83/CHANGES.txt
--
diff --cc CHANGES.txt
index 23e6c8b,76d155e..52775e7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,15 -1,5 +1,16 @@@
 -3.0.15
 +3.11.1
 + * Add a compaction option to TWCS to ignore sstables overlapping checks 
(CASSANDRA-13418)
 + * BTree.Builder memory leak (CASSANDRA-13754)
 + * Revert CASSANDRA-10368 of supporting non-pk column filtering due to 
correctness (CASSANDRA-13798)
 + * Fix cassandra-stress hang issues when an error during cluster connection 
happens (CASSANDRA-12938)
 + * Better bootstrap failure message when blocked by (potential) range 
movement (CASSANDRA-13744)
 + * "ignore" option is ignored in sstableloader (CASSANDRA-13721)
 + * Deadlock in AbstractCommitLogSegmentManager (CASSANDRA-13652)
 + * Duplicate the buffer before passing it to analyser in SASI operation 
(CASSANDRA-13512)
 + * Properly evict pstmts from prepared statements cache (CASSANDRA-13641)
 +Merged from 3.0:
+  * Range deletes in a CAS batch are ignored (CASSANDRA-13655)
 + * Avoid assertion error when IndexSummary > 2G (CASSANDRA-12014)
   * Change repair midpoint logging for tiny ranges (CASSANDRA-13603)
   * Better handle corrupt final commitlog segment (CASSANDRA-11995)
   * StreamingHistogram is not thread safe (CASSANDRA-13756)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fadf2e83/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fadf2e83/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
--
diff --cc src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
index 5683af4,e14ae6c..47920a4
--- a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
@@@ -226,8 -232,14 +232,10 @@@ public class CQL3CasRequest implements 
  PartitionUpdate update = new PartitionUpdate(cfm, key, 
updatedColumns(), conditions.size());
  for (RowUpdate upd : updates)
  upd.applyUpdates(current, update);
+ for (RangeDeletion upd : rangeDeletions)
+ upd.applyUpdates(current, update);
  
  Keyspace.openAndGetStore(cfm).indexManager.validate(update);
 -
 -if (isBatch)
 -BatchStatement.verifyBatchSize(Collections.singleton(update));
 -
  return update;
  }
  
@@@ -260,6 -272,29 +268,30 @@@
  }
  }
  
+ private class RangeDeletion
+ {
+ private final Slice slice;
+ private final ModificationStatement stmt;
+ private final QueryOptions options;
+ private final long timestamp;
+ 
+ private RangeDeletion(Slice slice, ModificationStatement stmt, 
QueryOptions options, long timestamp)
+ {
+ this.slice = slice;
+ this.stmt = stmt;
+ this.options = options;
+ this.timestamp = timestamp;
+ }
+ 
+ public void applyUpdates(FilteredPartition current, PartitionUpdate 
updates) throws InvalidRequestException
+ {
++// No slice statements currently require a read, but this 
maintains consistency with RowUpdate, and future proofs us
+ Map map = stmt.requiresRead() ? 
Collections.singletonMap(key, current) : null;
+ UpdateParameters params = new UpdateParameters(cfm, 
updates.columns(), options, timestamp, stmt.getTimeToLive(options), map);
+ stmt.addUpdateForKey(updates, slice, params);
+ }
+ }
+ 
  private static 

[3/7] cassandra git commit: Range deletes in a CAS batch are ignored

[jjirsa]

Range deletes in a CAS batch are ignored

Patch by Jeff Jirsa; Reviewed by Jay Zhuang, Sylvain Lebresne for 
CASSANDRA-13655


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

Branch: refs/heads/trunk
Commit: 433f24cb04dbcf74029a918ee73155f78d5f8111
Parents: ae88fd6
Author: Jeff Jirsa 
Authored: Mon Sep 11 09:35:01 2017 -0700
Committer: Jeff Jirsa 
Committed: Mon Sep 11 09:35:01 2017 -0700

--
 CHANGES.txt |   1 +
 .../cql3/statements/BatchStatement.java |  36 --
 .../cql3/statements/CQL3CasRequest.java |  31 ++
 .../cql3/statements/ModificationStatement.java  |  15 ++-
 .../org/apache/cassandra/cql3/BatchTests.java   |  51 +++--
 .../cql3/validation/operations/BatchTest.java   | 111 +++
 6 files changed, 219 insertions(+), 26 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/433f24cb/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f4360be..76d155e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.15
+ * Range deletes in a CAS batch are ignored (CASSANDRA-13655)
  * Change repair midpoint logging for tiny ranges (CASSANDRA-13603)
  * Better handle corrupt final commitlog segment (CASSANDRA-11995)
  * StreamingHistogram is not thread safe (CASSANDRA-13756)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/433f24cb/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
index 76a6460..cd9358c 100644
--- a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
@@ -417,18 +417,36 @@ public class BatchStatement implements CQLStatement
"IN on the clustering key columns is not supported with 
conditional %s",
statement.type.isUpdate()? "updates" : "deletions");
 
-Clustering clustering = 
Iterables.getOnlyElement(statement.createClustering(statementOptions));
+if (statement.hasSlices())
+{
+// All of the conditions require meaningful Clustering, not 
Slices
+assert !statement.hasConditions();
+
+Slices slices = statement.createSlices(statementOptions);
+// If all the ranges were invalid we do not need to do 
anything.
+if (slices.isEmpty())
+continue;
+
+for (Slice slice : slices)
+{
+casRequest.addRangeDeletion(slice, statement, 
statementOptions, timestamp);
+}
 
-if (statement.hasConditions())
+}
+else
 {
-statement.addConditions(clustering, casRequest, 
statementOptions);
-// As soon as we have a ifNotExists, we set 
columnsWithConditions to null so that everything is in the resultSet
-if (statement.hasIfNotExistCondition() || 
statement.hasIfExistCondition())
-columnsWithConditions = null;
-else if (columnsWithConditions != null)
-Iterables.addAll(columnsWithConditions, 
statement.getColumnsWithConditions());
+Clustering clustering = 
Iterables.getOnlyElement(statement.createClustering(statementOptions));
+if (statement.hasConditions())
+{
+statement.addConditions(clustering, casRequest, 
statementOptions);
+// As soon as we have a ifNotExists, we set 
columnsWithConditions to null so that everything is in the resultSet
+if (statement.hasIfNotExistCondition() || 
statement.hasIfExistCondition())
+columnsWithConditions = null;
+else if (columnsWithConditions != null)
+Iterables.addAll(columnsWithConditions, 
statement.getColumnsWithConditions());
+}
+casRequest.addRowUpdate(clustering, statement, 
statementOptions, timestamp);
 }
-casRequest.addRowUpdate(clustering, statement, statementOptions, 
timestamp);
 }
 
 return Pair.create(casRequest, columnsWithConditions);

[1/7] cassandra git commit: Added examples for compression and compaction

[jjirsa]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 ae88fd6c7 -> 433f24cb0
  refs/heads/cassandra-3.11 0fdbcc389 -> fadf2e839
  refs/heads/trunk 55d70173b -> 145d1a48f


Added examples for compression and compaction

patch by Jon Haddad; reviewed by Aleksey Yeschenko for CASSANDRA-13822


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

Branch: refs/heads/trunk
Commit: 0fdbcc389d83ea5dce40b3ba952c4144ceced795
Parents: 260475d
Author: Jon Haddad 
Authored: Fri Sep 8 12:38:21 2017 -0700
Committer: Jon Haddad 
Committed: Fri Sep 8 13:41:03 2017 -0700

--
 doc/source/cql/ddl.rst | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0fdbcc38/doc/source/cql/ddl.rst
--
diff --git a/doc/source/cql/ddl.rst b/doc/source/cql/ddl.rst
index 9c1946e..be87a7d 100644
--- a/doc/source/cql/ddl.rst
+++ b/doc/source/cql/ddl.rst
@@ -513,7 +513,7 @@ available:
compression. Custom compressor can 
be provided by specifying the full class
name as a “string 
constant”:#constants.
  ``enabled``   trueEnable/disable sstable compression.
- ``chunk_length_in_kb``64KBOn disk SSTables are compressed by 
block (to allow random reads). This
+ ``chunk_length_in_kb``64  On disk SSTables are compressed by 
block (to allow random reads). This
defines the size (in KB) of said 
block. Bigger values may improve the
compression rate, but increases the 
minimum size of data to be read from disk
for a read
@@ -525,6 +525,17 @@ available:
instance to check them every other 
read   |
 = === 
=
 
+
+For instance, to create a table with LZ4Compressor and a chunk_lenth_in_kb of 
4KB::
+
+   CREATE TABLE simple (
+  id int,
+  key text,
+  value text,
+  PRIMARY KEY (key, value)
+   ) with compression = {'class': 'LZ4Compressor', 'chunk_length_in_kb': 4};
+
+
 .. _cql-caching-options:
 
 Caching options
@@ -544,6 +555,17 @@ sub-options are available:
 to disable row caching.
  = 

 
+
+For instance, to create a table with both a key cache and 10 rows per 
partition::
+
+CREATE TABLE simple (
+id int,
+key text,
+value text,
+PRIMARY KEY (key, value)
+) WITH caching = {'keys': 'ALL', 'rows_per_partition': 10};
+
+
 Other considerations:
 #
 


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

[jira] [Updated] (CASSANDRA-13861) LCS ignores compaction thresholds in L0 STCS

[Chris Lohfink (JIRA)]

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

Chris Lohfink updated CASSANDRA-13861:
--
Reviewer: Jeff Jirsa

> LCS ignores compaction thresholds in L0 STCS
> 
>
> Key: CASSANDRA-13861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13861
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>
> min max compaction thresholds are hard coded to 4 and 32



--
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-13861) LCS ignores compaction thresholds in L0 STCS

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-13861:


GitHub user clohfink opened a pull request:

https://github.com/apache/cassandra/pull/150

Use compaction threshold for STCS in L0 for CASSANDRA-13861



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/clohfink/cassandra 13861

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cassandra/pull/150.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #150


commit ed584ec70a9f1889a317405aa869758145c3c6a5
Author: Chris Lohfink 
Date:   2017-09-11T16:07:40Z

Use compaction threshold for STCS in L0 for CASSANDRA-13861




> LCS ignores compaction thresholds in L0 STCS
> 
>
> Key: CASSANDRA-13861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13861
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>
> min max compaction thresholds are hard coded to 4 and 32



--
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-13861) LCS ignores compaction thresholds in L0 STCS

[Chris Lohfink (JIRA)]

Chris Lohfink created CASSANDRA-13861:
-

 Summary: LCS ignores compaction thresholds in L0 STCS
 Key: CASSANDRA-13861
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13861
 Project: Cassandra
  Issue Type: Bug
Reporter: Chris Lohfink
Assignee: Chris Lohfink


min max compaction thresholds are hard coded to 4 and 32



--
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-13339) java.nio.BufferOverflowException: null

[Chris Richards (JIRA)]

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

Chris Richards edited comment on CASSANDRA-13339 at 9/11/17 3:50 PM:
-

[~krummas] We're using Java 1.8.0-openjdk from CentOS 7.x.  I can't say for 
certain exactly what version it was using at the time we were seeing this (back 
in April/May of this year) but it is likely to have been 
java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64


was (Author: crichards):
@krummas We're using Java 1.8.0-openjdk from CentOS 7.x.  I can't say for 
certain exactly what version it was using at the time we were seeing this (back 
in April/May of this year) but it is likely to have been 
java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64

> java.nio.BufferOverflowException: null
> --
>
> Key: CASSANDRA-13339
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13339
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Chris Richards
>
> I'm seeing the following exception running Cassandra 3.9 (with Netty updated 
> to 4.1.8.Final) running on a 2 node cluster.  It would have been processing 
> around 50 queries/second at the time (mixture of 
> inserts/updates/selects/deletes) : there's a collection of tables (some with 
> counters some without) and a single materialized view.
> {code}
> ERROR [MutationStage-4] 2017-03-15 22:50:33,052 StorageProxy.java:1353 - 
> Failed to apply mutation locally : {}
> java.nio.BufferOverflowException: null
>   at 
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.writeUnsignedVInt(BufferedDataOutputStreamPlus.java:262)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.EncodingStats$Serializer.serialize(EncodingStats.java:233)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.SerializationHeader$Serializer.serializeForMessaging(SerializationHeader.java:380)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:122)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:89)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serialize(PartitionUpdate.java:790)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serialize(Mutation.java:393)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:279) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1347)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2539)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_121]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {code}
> and then again shortly afterwards
> {code}
> ERROR [MutationStage-3] 2017-03-15 23:27:36,198 StorageProxy.java:1353 - 
> Failed to apply mutation locally : {}
> java.nio.BufferOverflowException: null
>   at 
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> 

[jira] [Commented] (CASSANDRA-13339) java.nio.BufferOverflowException: null

[Chris Richards (JIRA)]

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

Chris Richards commented on CASSANDRA-13339:


@krummas We're using Java 1.8.0-openjdk from CentOS 7.x.  I can't say for 
certain exactly what version it was using at the time we were seeing this (back 
in April/May of this year) but it is likely to have been 
java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64

> java.nio.BufferOverflowException: null
> --
>
> Key: CASSANDRA-13339
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13339
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Chris Richards
>
> I'm seeing the following exception running Cassandra 3.9 (with Netty updated 
> to 4.1.8.Final) running on a 2 node cluster.  It would have been processing 
> around 50 queries/second at the time (mixture of 
> inserts/updates/selects/deletes) : there's a collection of tables (some with 
> counters some without) and a single materialized view.
> {code}
> ERROR [MutationStage-4] 2017-03-15 22:50:33,052 StorageProxy.java:1353 - 
> Failed to apply mutation locally : {}
> java.nio.BufferOverflowException: null
>   at 
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.writeUnsignedVInt(BufferedDataOutputStreamPlus.java:262)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.EncodingStats$Serializer.serialize(EncodingStats.java:233)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.SerializationHeader$Serializer.serializeForMessaging(SerializationHeader.java:380)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:122)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:89)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serialize(PartitionUpdate.java:790)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serialize(Mutation.java:393)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:279) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1347)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2539)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_121]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {code}
> and then again shortly afterwards
> {code}
> ERROR [MutationStage-3] 2017-03-15 23:27:36,198 StorageProxy.java:1353 - 
> Failed to apply mutation locally : {}
> java.nio.BufferOverflowException: null
>   at 
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.writeUnsignedVInt(BufferedDataOutputStreamPlus.java:262)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> 

[jira] [Comment Edited] (CASSANDRA-13339) java.nio.BufferOverflowException: null

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson edited comment on CASSANDRA-13339 at 9/11/17 3:23 PM:
--

[~crichards], [~theochu], [~vharseko] (or anyone else seeing this): which java 
version are you on?


was (Author: krummas):
[~crichards], [~theochu], [~vharseko] (or anyone else): which java version are 
you on?

> java.nio.BufferOverflowException: null
> --
>
> Key: CASSANDRA-13339
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13339
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Chris Richards
>
> I'm seeing the following exception running Cassandra 3.9 (with Netty updated 
> to 4.1.8.Final) running on a 2 node cluster.  It would have been processing 
> around 50 queries/second at the time (mixture of 
> inserts/updates/selects/deletes) : there's a collection of tables (some with 
> counters some without) and a single materialized view.
> {code}
> ERROR [MutationStage-4] 2017-03-15 22:50:33,052 StorageProxy.java:1353 - 
> Failed to apply mutation locally : {}
> java.nio.BufferOverflowException: null
>   at 
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.writeUnsignedVInt(BufferedDataOutputStreamPlus.java:262)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.EncodingStats$Serializer.serialize(EncodingStats.java:233)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.SerializationHeader$Serializer.serializeForMessaging(SerializationHeader.java:380)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:122)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:89)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serialize(PartitionUpdate.java:790)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serialize(Mutation.java:393)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:279) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1347)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2539)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_121]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {code}
> and then again shortly afterwards
> {code}
> ERROR [MutationStage-3] 2017-03-15 23:27:36,198 StorageProxy.java:1353 - 
> Failed to apply mutation locally : {}
> java.nio.BufferOverflowException: null
>   at 
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.writeUnsignedVInt(BufferedDataOutputStreamPlus.java:262)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> 

[jira] [Commented] (CASSANDRA-13339) java.nio.BufferOverflowException: null

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-13339:
-

[~crichards], [~theochu], [~vharseko] (or anyone else): which java version are 
you on?

> java.nio.BufferOverflowException: null
> --
>
> Key: CASSANDRA-13339
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13339
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Chris Richards
>
> I'm seeing the following exception running Cassandra 3.9 (with Netty updated 
> to 4.1.8.Final) running on a 2 node cluster.  It would have been processing 
> around 50 queries/second at the time (mixture of 
> inserts/updates/selects/deletes) : there's a collection of tables (some with 
> counters some without) and a single materialized view.
> {code}
> ERROR [MutationStage-4] 2017-03-15 22:50:33,052 StorageProxy.java:1353 - 
> Failed to apply mutation locally : {}
> java.nio.BufferOverflowException: null
>   at 
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.writeUnsignedVInt(BufferedDataOutputStreamPlus.java:262)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.EncodingStats$Serializer.serialize(EncodingStats.java:233)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.SerializationHeader$Serializer.serializeForMessaging(SerializationHeader.java:380)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:122)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:89)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serialize(PartitionUpdate.java:790)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serialize(Mutation.java:393)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:279) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1347)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2539)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_121]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {code}
> and then again shortly afterwards
> {code}
> ERROR [MutationStage-3] 2017-03-15 23:27:36,198 StorageProxy.java:1353 - 
> Failed to apply mutation locally : {}
> java.nio.BufferOverflowException: null
>   at 
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.writeUnsignedVInt(BufferedDataOutputStreamPlus.java:262)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.EncodingStats$Serializer.serialize(EncodingStats.java:233)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> 

[jira] [Commented] (CASSANDRA-13619) java.nio.BufferOverflowException: null while flushing hints

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-13619:
-

Does not repro with Oracles 1.8.0_144 for me either

> java.nio.BufferOverflowException: null while flushing hints
> ---
>
> Key: CASSANDRA-13619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13619
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination, Core
>Reporter: Milan Milosevic
>Assignee: Marcus Eriksson
>
> I'm seeing the following exception running Cassandra 3.0.11 on 21 node 
> cluster in two AWS regions when half of the nodes in one region go down, and 
> the load is high on the rest of the nodes:
> {code}
> WARN  [SharedPool-Worker-10] 2017-06-14 12:57:15,017 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-10,5,main]: {}
> java.lang.RuntimeException: java.nio.BufferOverflowException
> at 
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2549)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0-zing_17.03.1.0]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.0.11.jar:3.0.11]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.11.jar:3.0.11]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0-zing_17.03.1.0]
> Caused by: java.nio.BufferOverflowException: null
> at 
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:195)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.writeUnsignedVInt(BufferedDataOutputStreamPlus.java:258)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.Columns$Serializer.serialize(Columns.java:405) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.SerializationHeader$Serializer.serializeForMessaging(SerializationHeader.java:407)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:120)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serialize(PartitionUpdate.java:625)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serialize(Mutation.java:305)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.Hint$Serializer.serialize(Hint.java:141) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.HintsBuffer$Allocation.write(HintsBuffer.java:251) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.HintsBuffer$Allocation.write(HintsBuffer.java:230) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.HintsBufferPool.write(HintsBufferPool.java:61) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.HintsService.write(HintsService.java:154) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.service.StorageProxy$11.runMayThrow(StorageProxy.java:2627)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2545)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> ... 5 common frames omitted
> {code}
> Relevant configurations from cassandra.yaml:
> {code}
> -cassandra_hinted_handoff_throttle_in_kb: 1024
>  cassandra_max_hints_delivery_threads: 4
> -cassandra_hints_flush_period_in_ms: 1
> -cassandra_max_hints_file_size_in_mb: 512
> {code}
> When I reduce -cassandra_hints_flush_period_in_ms: 1 to 5000, the number 
> of exceptions lowers significantly, but they are still present.



--

[jira] [Commented] (CASSANDRA-12960) Pending hinted hand-offs are replayed after TRUNCATE

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-12960:
---

See {{Hint.isLive()}}. We both keep truncation records, and look at them when 
replaying hints, doing exactly what [~jasonstack] suggested here. 
{{BatchlogManager}} also has similar code to avoid replaying truncated 
mutations.

The overall problem with truncate however is that it itself is not atomic, and 
can fail partially. You should not use it in production, because it requires 
the whole cluster to be up, and well-behaving, and for nothing to go wrong 
while truncate is being issued. If a node goes down after availability was 
validated, but before getting truncate command, you are in all sorts of trouble.

> Pending hinted hand-offs are replayed after TRUNCATE
> 
>
> Key: CASSANDRA-12960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12960
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: Cassandra 2.2.8
> Amazon Linux AMI 2016.03
>Reporter: Yuji Ito
>Priority: Minor
> Attachments: stale_data.sh
>
>
> I could read stale data after truncating a table.
> The issue happens when the truncation is executed while a node is starting.
> According to logs, pending hinted hand-offs were replayed after the 
> truncation.
> *cluster*:
> - C* 2.2.8
> - a cluster has 3 nodes
> - replication_factor: 3
> *steps to reproduce* (the attached script):
> # kill a node
> # insert/update some records
> # restart the killed node
> # truncate the table (not to wait for the killed node's startup)
> # kill another node (this step isn't essential)
> # read all data



--
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-13619) java.nio.BufferOverflowException: null while flushing hints

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-13619:
---

On MacOS, with Oracle's "1.8.0_144", cannot reproduce either.

> java.nio.BufferOverflowException: null while flushing hints
> ---
>
> Key: CASSANDRA-13619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13619
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination, Core
>Reporter: Milan Milosevic
>Assignee: Marcus Eriksson
>
> I'm seeing the following exception running Cassandra 3.0.11 on 21 node 
> cluster in two AWS regions when half of the nodes in one region go down, and 
> the load is high on the rest of the nodes:
> {code}
> WARN  [SharedPool-Worker-10] 2017-06-14 12:57:15,017 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-10,5,main]: {}
> java.lang.RuntimeException: java.nio.BufferOverflowException
> at 
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2549)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0-zing_17.03.1.0]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.0.11.jar:3.0.11]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.11.jar:3.0.11]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0-zing_17.03.1.0]
> Caused by: java.nio.BufferOverflowException: null
> at 
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:195)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.writeUnsignedVInt(BufferedDataOutputStreamPlus.java:258)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.Columns$Serializer.serialize(Columns.java:405) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.SerializationHeader$Serializer.serializeForMessaging(SerializationHeader.java:407)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:120)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serialize(PartitionUpdate.java:625)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serialize(Mutation.java:305)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.Hint$Serializer.serialize(Hint.java:141) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.HintsBuffer$Allocation.write(HintsBuffer.java:251) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.HintsBuffer$Allocation.write(HintsBuffer.java:230) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.HintsBufferPool.write(HintsBufferPool.java:61) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.HintsService.write(HintsService.java:154) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.service.StorageProxy$11.runMayThrow(StorageProxy.java:2627)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2545)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> ... 5 common frames omitted
> {code}
> Relevant configurations from cassandra.yaml:
> {code}
> -cassandra_hinted_handoff_throttle_in_kb: 1024
>  cassandra_max_hints_delivery_threads: 4
> -cassandra_hints_flush_period_in_ms: 1
> -cassandra_max_hints_file_size_in_mb: 512
> {code}
> When I reduce -cassandra_hints_flush_period_in_ms: 1 to 5000, the number 
> of exceptions lowers significantly, but they are still 

[jira] [Updated] (CASSANDRA-13860) Make pulling schema from remote nodes more lightweight

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-13860:
--
Issue Type: Sub-task  (was: Improvement)
Parent: CASSANDRA-9424

> Make pulling schema from remote nodes more lightweight
> --
>
> Key: CASSANDRA-13860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13860
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Distributed Metadata
>Reporter: Aleksey Yeschenko
> Fix For: 4.x
>
>
> Our current mechanism for resolving schema differences detected via gossip is 
> quite heavyweight: we request the complete schema from a node, which often 
> results in some very heavy mutations. But in most cases this shouldn't be 
> necessary, as the delta is usually quite small.
> We may want to instead negotiate the difference based on schema graph merkle 
> tree (all -> keyspace -> tables/views/types/etc.). This assumes that by then 
> we'd switch to calculating schema digests bases on in-memory representation 
> of {{Schema}}, without going to disk.



--
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-13860) Make pulling schema from remote nodes more lightweight

[Aleksey Yeschenko (JIRA)]

Aleksey Yeschenko created CASSANDRA-13860:
-

 Summary: Make pulling schema from remote nodes more lightweight
 Key: CASSANDRA-13860
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13860
 Project: Cassandra
  Issue Type: Improvement
  Components: Distributed Metadata
Reporter: Aleksey Yeschenko
 Fix For: 4.x


Our current mechanism for resolving schema differences detected via gossip is 
quite heavyweight: we request the complete schema from a node, which often 
results in some very heavy mutations. But in most cases this shouldn't be 
necessary, as the delta is usually quite small.

We may want to instead negotiate the difference based on schema graph merkle 
tree (all -> keyspace -> tables/views/types/etc.). This assumes that by then 
we'd switch to calculating schema digests bases on in-memory representation of 
{{Schema}}, without going to disk.



--
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-13339) java.nio.BufferOverflowException: null

[Chris Richards (JIRA)]

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

Chris Richards commented on CASSANDRA-13339:


[~jbrown] In my system, there are two datacenters.  There are counters, batches 
(both BatchType.COUNTER and BatchType.LOGGED), and a materialized view.

I did add some code to dump the mutation when I thought that this was about to 
occur - looking back over the logs, I see this being reported for even the most 
basic INSERT statement (on a table without a counter).  Now, I haven't 
_entirely_ proven that these are exactly the right events for this ticket (the 
code change looks for empty mutations prior to serialization, catches the 
IOException and logs the "as_string" of the mutation along with the original 
size expected for serialization and the actual size of the serialization - and 
then tries the write again), but I never saw it crash with these changes in 
place.

Clearly the changes I'm running with are by no means a fix - they are at best 
an ugly work-around to try and gain more information and keep my system alive.

> java.nio.BufferOverflowException: null
> --
>
> Key: CASSANDRA-13339
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13339
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Chris Richards
>
> I'm seeing the following exception running Cassandra 3.9 (with Netty updated 
> to 4.1.8.Final) running on a 2 node cluster.  It would have been processing 
> around 50 queries/second at the time (mixture of 
> inserts/updates/selects/deletes) : there's a collection of tables (some with 
> counters some without) and a single materialized view.
> {code}
> ERROR [MutationStage-4] 2017-03-15 22:50:33,052 StorageProxy.java:1353 - 
> Failed to apply mutation locally : {}
> java.nio.BufferOverflowException: null
>   at 
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.writeUnsignedVInt(BufferedDataOutputStreamPlus.java:262)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.EncodingStats$Serializer.serialize(EncodingStats.java:233)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.SerializationHeader$Serializer.serializeForMessaging(SerializationHeader.java:380)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:122)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:89)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serialize(PartitionUpdate.java:790)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serialize(Mutation.java:393)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:279) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1347)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2539)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_121]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {code}
> and then again shortly afterwards
> 

[jira] [Commented] (CASSANDRA-13069) Local batchlog for MV may not be correctly written on node movements

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-13069:
--

What I had in mind was more about simplifying the whole view write patch to be 
1) write a batchlog for local+view mutations and then 2) apply those mutations, 
which implied rewriting {{Keyspace.apply}} so we don't start by writing the 
base mutation in the commit log for instance, and I still think it would be 
both simpler code-wise and be more easy to reason about correction. But this is 
admittedly not the place to debate about this, and you are right that things 
aren't as grim as I portrayed it in my previous comment anyway, so happy to 
focus on just the bug for which this was opened for.

So things mostly look good except for the {{isFirstReplay}} addition in 
{{BatchLogManager}} that I'm fairly unsure about. My understanding is that the 
main goal of the batchlog delay is to avoid replaying batches that may still 
have a change to succeed, but your change seems to break that, so it sounds 
like that could have adverse performance effect, including on non-view usages 
of the batchlog. To be honest though, the batchlog code isn't my main area of 
expertise, so if if you feel this is important and not a real problem, I'd 
prefer we isolate that change to a separate ticket so it is looked in its own 
right (and preferably by someone more knowledgeable of that code).


> Local batchlog for MV may not be correctly written on node movements
> 
>
> Key: CASSANDRA-13069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13069
> Project: Cassandra
>  Issue Type: Bug
>  Components: Materialized Views
>Reporter: Sylvain Lebresne
>Assignee: Paulo Motta
>
> Unless I'm really reading this wrong, I think the code 
> [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageProxy.java#L829-L843],
>  which comes from CASSANDRA-10674, isn't working properly.
> More precisely, I believe we can have both paired and unpaired mutations, so 
> that both {{if}} can be taken, but if that's the case, the 2nd write to the 
> batchlog will basically overwrite (remove) the batchlog write of the 1st 
> {{if}} and I don't think that's the intention. In practice, this means 
> "paired" mutation won't be in the batchlog, which mean they won't be replayed 
> at all if they fail.



--
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

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-12373:
-

bq. In the ctor, for isDense, we seem to force re-computation for non-SC 
non-dense tables (which happens to include non-compact tables).

Corrected it. This didn't cause any trouble (because was checking for an empty 
name, too), but now we'll recompute only for the supercolumn ones, which is 
much better.

bq. But for I'm also not 100% sure this work in all upgrade scenario.

Thing is the re-computation is necessary only for the upgrade from 2.x -> 
current 3.x -> 3.x + this patch, in which case we have two clustering columns 
instead of one just a single "empty" value column, which is a collection. 
3.x-created supercolumns are calculated correctly 
[here|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/thrift/ThriftConversion.java#L184].

You are right that some testing in that regard won't hurt, so I've added some 
3-step upgrade tests with the scenarios similar to the current one. For the 
sakes of completeness, I've also added a test for current 3.x -created 
supercolumn families. 

bq. Unfortunately, while we were supposed to have a SC upgrade dtests

I've added some dtests as well as upgrade tests.

bq. I'm not entirely sure if/how column renaming works for the SC key and value 
"fake" column

You're right: I did leave it off as I thought read/write path is the only 
support that's required for migrating off SCF, but adding this is trivial. I've 
added tests for all sorts of renames. However, there is no special-casing done 
in {{AlterStatement}}: {{getColumnDefinition}} would return the "fake" columns 
as well. {{removeColumn}} would be a no-op in case of fake columns and adding 
column would force re-initialisation and the new column would get picked up 
correctly.

bq. In UpdateParameters#addCounter, not sure the change from 
CounterContext#createUpdate to CounterContext#createLocal is corret.

Yes, sorry, I have overlooked it. 

bq. In getSuperCfKeyColumn, not sure what "3.x-created supercolumn family" 
refers to (is that SC tables created from thrift in 3.x? or SC tables whose 
schema had been upgraded by a previous 3.x version?) and more importantly, why 
it would differ in number of clustering columns?

You are right, SC columns created from Thrift in 3.x. When upgrading from 2.x, 
you'll get {{column1}} and {{column2}} as clustering keys (which they kind of 
are). When created via thrift in 3.x, {{column2}} is entirely virtual (which it 
kind of is). 

bq. There is a typo in a comment, where in "... can't be change to support 
inclusive slice ...", I believe you want "exclusive".

Fixed.

bq. in the 2nd branch (else if ...), we should use result.add(cell) directly. 
Not only does that already handle counters, but more importantly, if we don't 
do that, things like ttl(v) will not work on the compact column value.

Good point. Fixed.

bq. the last else is confusing: by definition we shouldn't be exposing any 
other column than the "compact value" column, so that branch should probably 
not be there (or be an assertion that we shouldn't get there).

You're right. This is an artefact of the previous incorrect dense table 
handling.

bq. In the updates loop in prepareUpdateOperations, not sure why the 2 first 
cases seem to assume that cfm.isSuperColumnValueColumn(def), but the 3rd case 
tests it explicitely (but after having assigned superColumnValue). In general, 
not sure why the 3rd case looks different from the other 2. Also, I find it a 
bit hard to follow the mix of if using continue and sometime using else, 
sometimes not. I'm personally prefer using else when needed and remove all the 
continue. Lastly, seems the method could use a check for superColumnKey != null.

I've refactored this method even further. There were many things that were 
technically correct, but were added on earlier stages, so got there 
historically. Also, did a bit of further improvements with 
{{collectMarkerSpecifications}}

bq. In prepareInsertForJSONOperations, I believe the 2nd call to 
getRawTermForColumn is unecessary, you can use the raw for before the if. 
Further, the overall code of this method feels very similar to the one in 
prepareInsertOperations: can we extract the bulk of what's common? (the loop 
seems to be operating on a ColumnDefinition and the associated value, so either 
pass an Iterable>, or build 2 lists; I don't think we care about the 
performance difference here).

Refactored this part as well.

bq. In prepareDeleteOperations, need to fix the "Maybe not single only" 
comment. 

I think what was meant was "not only {{SingleColumnRelation}}", but this is not 
true: multi column operations are not allowed. After writing more tests, I did 
discover that multi-column restrictions were not working 

[jira] [Comment Edited] (CASSANDRA-13787) RangeTombstoneMarker and ParitionDeletion is not properly included in MV

[ZhaoYang (JIRA)]

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

ZhaoYang edited comment on CASSANDRA-13787 at 9/11/17 8:36 AM:
---

| source |  test  |   dtest |
| [trunk|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13787-trunk] 
| [passed|https://circleci.com/gh/jasonstack/cassandra/571] | {{passed on 
local:}}
repair_tests.repair_test.TestRepair.local_dc_repair_test
{{failed on trunk:}}
repair_tests.repair_test.TestRepair.simple_parallel_repair_test
repair_tests.repair_test.TestRepair.test_dead_sync_initiator
rebuild_test.TestRebuild.rebuild_ranges_test
repair_tests.repair_test.TestRepair.dc_repair_test
topology_test.TestTopology.simple_decommission_test
disk_balance_test.TestDiskBalance.disk_balance_decommission_test
repair_tests.repair_test.TestRepair.simple_sequential_repair_test
repair_tests.repair_test.TestRepair.thread_count_repair_test
upgrade_internal_auth_test.TestAuthUpgrade.upgrade_to_22_test
cdc_test.TestCDC.test_insertion_and_commitlog_behavior_after_reaching_cdc_total_space
cdc_test.TestCDC.test_insertion_and_commitlog_behavior_after_reaching_cdc_total_space|
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13787-3.11] | 
[passed|https://circleci.com/gh/jasonstack/cassandra/573] | {{passed on local:}}
batch_test.TestBatch.logged_batch_doesnt_throw_uae_test
repair_tests.incremental_repair_test.TestIncRepair.multiple_repair_test
{{failed on 3.11}}
batch_test.TestBatch.batchlog_replay_compatibility_1_test
batch_test.TestBatch.batchlog_replay_compatibility_4_test
upgrade_internal_auth_test.TestAuthUpgrade.upgrade_to_22_test
upgrade_internal_auth_test.TestAuthUpgrade.upgrade_to_30_test |
| [3.0|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13787-3.0] | 
[passed|https://circleci.com/gh/jasonstack/cassandra/572] | {{passed on local}}
batch_test.TestBatch.logged_batch_throws_uae_test
{{also failed on cassandra-3.0}}
offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
upgrade_internal_auth_test.TestAuthUpgrade.upgrade_to_22_test
global_row_key_cache_test.TestGlobalRowKeyCache.functional_test
batch_test.TestBatch.batchlog_replay_compatibility_1_test
batch_test.TestBatch.batchlog_replay_compatibility_4_test
upgrade_internal_auth_test.TestAuthUpgrade.upgrade_to_30_test
auth_test.TestAuth.system_auth_ks_is_alterable_test|

Failing dtests are either failing on trunk or passed on local.



was (Author: jasonstack):
| source |  test  |   dtest |
| [trunk|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13787-trunk] 
| [passed|https://circleci.com/gh/jasonstack/cassandra/571] | (off) trunk-dtest 
hang due to netty messaging... |
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13787-3.11] | 
[passed|https://circleci.com/gh/jasonstack/cassandra/573] | 
batch_test.TestBatch.batchlog_replay_compatibility_1_test
batch_test.TestBatch.batchlog_replay_compatibility_4_test
upgrade_internal_auth_test.TestAuthUpgrade.upgrade_to_22_test
upgrade_internal_auth_test.TestAuthUpgrade.upgrade_to_30_test |
| [3.0|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13787-3.0] | 
[passed|https://circleci.com/gh/jasonstack/cassandra/572] | these tests failed 
on cassandra-3.0 as well:
upgrade_internal_auth_test.TestAuthUpgrade.upgrade_to_22_test
global_row_key_cache_test.TestGlobalRowKeyCache.functional_test
batch_test.TestBatch.batchlog_replay_compatibility_1_test
batch_test.TestBatch.batchlog_replay_compatibility_4_test
upgrade_internal_auth_test.TestAuthUpgrade.upgrade_to_30_test
auth_test.TestAuth.system_auth_ks_is_alterable_test|

> RangeTombstoneMarker and ParitionDeletion is not properly included in MV
> 
>
> Key: CASSANDRA-13787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13787
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Materialized Views
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>
> Found two problems related to MV tombstone. 
> 1. Range-tombstone-Marker being ignored after shadowing first row, subsequent 
> base rows are not shadowed in TableViews.
> If the range tombstone was not flushed, it was used as deleted row to 
> shadow new updates. It works correctly.
> After range tombstone was flushed, it was used as RangeTombstoneMarker 
> and being skipped after shadowing first update. The bound of 
> RangeTombstoneMarker seems wrong, it contained full clustering, but it should 
> contain range or it should be multiple RangeTombstoneMarkers for multiple 
> slices(aka. new updates)
> -2. Partition tombstone is not used when no existing live data, it will 
> resurrect deleted cells. It was found in 11500 and included in that patch.- 
> (Merged in CASSANDRA-11500)
> In order not 

[jira] [Updated] (CASSANDRA-13724) Externalize and cleanup build.xml dependencies

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13724:
---
Summary: Externalize and cleanup build.xml dependencies  (was: Cleanup 
build.xml dependencies)

> Externalize and cleanup build.xml dependencies
> --
>
> Key: CASSANDRA-13724
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13724
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Minor
> Fix For: 4.x
>
>
> As discussed in CASSANDRA-12996, the build.xml has become pretty messy and 
> could use some cleanup and additional inline comments. Maybe parts of it 
> could be even split up or externalized.



--
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-13724) Cleanup build.xml dependencies

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13724:
---
Status: Patch Available  (was: In Progress)

I've now externalized all dependencies to real pom files that can be found in a 
separate [pom 
dir|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-13724/pom]. 
Instead of always generating the poms with our current approach, the new static 
poms will get installed or deployed as they are. Any changes to project 
dependencies will be done directly by editing the pom files and you should 
never have to change build.xml for that. As a side effect, build.xml has been 
reduced to "only" <1500 loc.

All ant targets should work exactly as before. Also, all build artifacts should 
match with artifacts build with current build.xml, although I wasn't able to 
test the deploy target yet.

> Cleanup build.xml dependencies
> --
>
> Key: CASSANDRA-13724
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13724
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Minor
> Fix For: 4.x
>
>
> As discussed in CASSANDRA-12996, the build.xml has become pretty messy and 
> could use some cleanup and additional inline comments. Maybe parts of it 
> could be even split up or externalized.



--
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-13710) Add a nodetool command to display details of any tables containing unowned tokens

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-13710:
-

[~varung] thanks, I've assigned it to you. I agree that this new switch should 
be able to be applied to any existing variant of the cleanup command. 

> Add a nodetool command to display details of any tables containing unowned 
> tokens
> -
>
> Key: CASSANDRA-13710
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13710
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Observability, Tools
>Reporter: Sam Tunnicliffe
>Assignee: Varun Gupta
>
> This could be implemented as a {{dry-run}} switch for {{nodetool cleanup}}



--
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-13710) Add a nodetool command to display details of any tables containing unowned tokens

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe reassigned CASSANDRA-13710:
---

Assignee: Varun Gupta

> Add a nodetool command to display details of any tables containing unowned 
> tokens
> -
>
> Key: CASSANDRA-13710
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13710
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Observability, Tools
>Reporter: Sam Tunnicliffe
>Assignee: Varun Gupta
>
> This could be implemented as a {{dry-run}} switch for {{nodetool cleanup}}



--
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