[jira] [Commented] (CASSANDRA-8527) Account for range tombstones wherever we account for tombstones

[Alexander Dejanovski (JIRA)]

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

Alexander Dejanovski commented on CASSANDRA-8527:
-

I pushed a small fix in my branch to avoid counting some rows in both 
{{deletedRows}} and {{tombstones}}.

If all cells in a row have expired then each will get counted as a tombstone 
but it will also make {{row.hasLiveData() }} return false. 
I've changed the test to : 

{code:java}
if (row.hasLiveData(ReadCommand.this.nowInSec(), enforceStrictLiveness))
++liveRows;
else if (!row.primaryKeyLivenessInfo().isLive(ReadCommand.this.nowInSec()))
{
++deletedRows;
}
{code}

Also started the discussion on the dev ML today.

> Account for range tombstones wherever we account for tombstones
> ---
>
> Key: CASSANDRA-8527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8527
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Alexander Dejanovski
> Fix For: 4.x
>
> Attachments: CASSANDRA-8527.diff
>
>
> As discussed in CASSANDRA-8477, we should make sure the tombstone thresholds 
> also apply to range tombstones, since they poses the same problems than cell 
> tombstones.



--
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-14126) don't work udf javascripts

[Alex Lourie (JIRA)]

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

Alex Lourie reassigned CASSANDRA-14126:
---

Assignee: Alex Lourie

> don't work udf javascripts
> --
>
> Key: CASSANDRA-14126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14126
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Denis Pershin
>Assignee: Alex Lourie
>Priority: Minor
>  Labels: security
> Fix For: 3.11.x
>
> Attachments: cassandra-01.yaml, cassandra-02.yaml, cassandra-03.yaml
>
>
> * config:
> {code}
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> {code}
> * create keyspace:
> {code}
> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' : 'SimpleStrategy', 
> 'replication_factor' : 1 };
> {code}
> * in testkeyspace create function:
> {code}
> CREATE OR REPLACE FUNCTION first_int(input set) RETURNS NULL ON NULL 
> INPUT RETURNS int LANGUAGE javascript AS '(function(){var result = 2;return 
> result;})();';
> {code}
> * create table and insert:
> {code}
> create table A (id int primary key, val set);
> insert into A  (id, val) values (1, {3,5,7,1});
> {code}
> * select:
> {code}
> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
>  line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure] 
> message="execution of 'testkeyspace.first_int[set]' failed: 
> java.security.AccessControlException: access denied: 
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}
> raw log:
> {code}
> root@001b19bd3cc6:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> USE testkeyspace ;
> cqlsh:testkeyspace> CREATE OR REPLACE FUNCTION first_int(input set) 
> RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE javascript AS 
> '(function(){var result = 2;return result;})();';
> cqlsh:testkeyspace> create table A (id int primary key, val set);
> cqlsh:testkeyspace> insert into A  (id, val) values (1, {3,5,7,1});
> cqlsh:testkeyspace> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
>  line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure] 
> message="execution of 'testkeyspace.first_int[set]' failed: 
> java.security.AccessControlException: access denied: 
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}



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

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

[jira] [Commented] (CASSANDRA-14126) don't work udf javascripts

[Alex Lourie (JIRA)]

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

Alex Lourie commented on CASSANDRA-14126:
-

I'm going to have a poke at this one.

> don't work udf javascripts
> --
>
> Key: CASSANDRA-14126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14126
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Denis Pershin
>Priority: Minor
>  Labels: security
> Fix For: 3.11.x
>
> Attachments: cassandra-01.yaml, cassandra-02.yaml, cassandra-03.yaml
>
>
> * config:
> {code}
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> {code}
> * create keyspace:
> {code}
> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' : 'SimpleStrategy', 
> 'replication_factor' : 1 };
> {code}
> * in testkeyspace create function:
> {code}
> CREATE OR REPLACE FUNCTION first_int(input set) RETURNS NULL ON NULL 
> INPUT RETURNS int LANGUAGE javascript AS '(function(){var result = 2;return 
> result;})();';
> {code}
> * create table and insert:
> {code}
> create table A (id int primary key, val set);
> insert into A  (id, val) values (1, {3,5,7,1});
> {code}
> * select:
> {code}
> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
>  line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure] 
> message="execution of 'testkeyspace.first_int[set]' failed: 
> java.security.AccessControlException: access denied: 
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}
> raw log:
> {code}
> root@001b19bd3cc6:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> USE testkeyspace ;
> cqlsh:testkeyspace> CREATE OR REPLACE FUNCTION first_int(input set) 
> RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE javascript AS 
> '(function(){var result = 2;return result;})();';
> cqlsh:testkeyspace> create table A (id int primary key, val set);
> cqlsh:testkeyspace> insert into A  (id, val) values (1, {3,5,7,1});
> cqlsh:testkeyspace> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
>  line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure] 
> message="execution of 'testkeyspace.first_int[set]' failed: 
> java.security.AccessControlException: access denied: 
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}



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

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

[jira] [Commented] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>

[Alex Lourie (JIRA)]

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

Alex Lourie commented on CASSANDRA-14054:
-

[~mkjellman]

I've run the test on CircleCI with your configuration another 20 times and all 
pass successfully. So it might indeed be some kind of a racing condition in 
your environment.

The following is the code tested:

{code:java}
 updateView("UPDATE %s USING TIMESTAMP 1 SET c = ?, val = ? WHERE k = ?", 0, 0, 
0);
 updateView("UPDATE %s USING TIMESTAMP 3 SET c = ? WHERE k = ?", 1, 0);
 updateView("UPDATE %s USING TIMESTAMP 2 SET val = ? WHERE k = ?", 1, 0);
 updateView("UPDATE %s USING TIMESTAMP 4 SET c = ? WHERE k = ?", 2, 0);
 updateView("UPDATE %s USING TIMESTAMP 3 SET val = ? WHERE k = ?", 2, 0);

 assertRows(execute("SELECT c, k, val FROM mv_rctstest"), row(2, 0, 2));
 assertRows(execute("SELECT c, k, val FROM mv_rctstest limit 1"), row(2, 0, 2));
{code}

This code works on the same data, as it updates the same row. It is possible 
that due to unclear timing peculiarities, the assert runs before the update had 
propagated to all the replicas; or that it runs even before the update has 
applied to the row on any replica. Even though that would be extremeley strange 
in the environment where the tests are run.

We could do something like you suggesting, adding  
"getCurrentColumnFamilyStore().forceBlockingFlush();" before the asserts.

It seems that I can't reproduce this in my environment. Is there anything 
specific that your environment may have that mine doesn't?


> testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is 
> flaky: expected <2> but got <1>
> -
>
> Key: CASSANDRA-14054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14054
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>
> testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is 
> flaky: expected <2> but got <1>
> Fails about 25% of the time. It is currently our only flaky unit test on 
> trunk so it would be great to get this one fixed up so we can be confident in 
> unit test failures going forward.
> junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of 
> type int), expected <2> but got <1>
>   at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973)
>   at 
> org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380)



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

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

[jira] [Resolved] (CASSANDRA-11955) Impossibly large value displayed for data "load" and "Space used (*):"

[Nate McCall (JIRA)]

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

Nate McCall resolved CASSANDRA-11955.
-
Resolution: Cannot Reproduce

[~jjirsa] Agreed - have not seen this in some time, most likely covered by 
other fixes. Closing as cannot reproduce.

> Impossibly large value displayed for data "load" and "Space used (*):"
> --
>
> Key: CASSANDRA-11955
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11955
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Nate McCall
>  Labels: proposed-cantrepro
>
> The data load as reported by nodetool views looks like it is not getting 
> updated correctly (from compaction?):
> {noformat}
> # nodetool status
> Datacenter: dc1
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  Address Load   Tokens   Owns (effective)  Host ID 
>   Rack
> UJ  [redacted]   1.1 GB 256  ? 
> 0dfd164c-b874-4e90-be2c-3fea8e12d78e  a
> UN  [redacted]   14.96 TB   256  49.0% 
> 02821ddb-a463-4845-b2ca-bed1da141e81  a
> UN  [redacted] 31.94 TB   256  51.2% 
> 30531bfe-fe0e-4360-a22b-36bf200a9679  e
> UN  [redacted]   1.81 TB256  54.0% 
> 17a93464-41c4-49f8-8042-b2741c5e3256  d
> UN  [redacted]   22.2 TB256  46.0% 
> f35b4aeb-33e5-4f53-bc9d-49de3a157e3e  d
> UN  [redacted]28.53 TB   256  51.0% 
> 74e04517-de70-4754-82fc-2dc867a14ae7  a
> UN  [redacted]  39.25 TB   256  48.8% 
> 3a271443-db02-4487-be52-d6c35b66da40  e
> {noformat}
> NOTE: unknown if the join is related as the "TB" vs. "GB" discrepancy was 
> only noticed after the join started.
> And same for {{nodetool tablestats}} details of the {{30531bfe...}} node: 
> {noformat}
> # nodetool tablestats
> Keyspace: myks
> Read Count: 1306765640
> Read Latency: 0.22125289495291597 ms.
> Write Count: 3375354023
> Write Latency: 0.017621884565795665 ms.
> Pending Flushes: 0
> Table: mytable
> SSTable count: 110
> Space used (live): 31374649977187
> Space used (total): 31374649977187
> Space used by snapshots (total): 0
> ...
> {noformat}
> Nothing fancy on this table (there is only one active table on this cluster): 
> STCS with defaults, no MVs, no indexes just text and int columns with a 
> single value partition key. 
> NOTE: once restarted, the values then display as correct, creeping up from 
> there (thus my thinking that this is a compaction 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] [Updated] (CASSANDRA-14106) utest failed: DistributionSequenceTest.setSeed() and simpleSequence()

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-14106:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

+1, committed to trunk as {{1db54a1266a68d9c765c0fa248277635c4520f6d}}. Thanks 
[~jay.zhuang]!

> utest failed: DistributionSequenceTest.setSeed() and simpleSequence()
> -
>
> Key: CASSANDRA-14106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14106
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> To reproduce:
> {noformat}
> $ ant stress-test -Dtest.name=DistributionSequenceTest
> {noformat}
> {noformat}
> stress-test:
> [junit] Testsuite: 
> org.apache.cassandra.stress.generate.DistributionSequenceTest
> [junit] Testsuite: 
> org.apache.cassandra.stress.generate.DistributionSequenceTest Tests run: 4, 
> Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.08 sec
> [junit]
> [junit] Testcase: 
> simpleSequence(org.apache.cassandra.stress.generate.DistributionSequenceTest):
> FAILED
> [junit] expected:<5> but was:<4>
> [junit] junit.framework.AssertionFailedError: expected:<5> but was:<4>
> [junit] at 
> org.apache.cassandra.stress.generate.DistributionSequenceTest.simpleSequence(DistributionSequenceTest.java:37)
> [junit]
> [junit]
> [junit] Testcase: 
> setSeed(org.apache.cassandra.stress.generate.DistributionSequenceTest):   
> FAILED
> [junit] expected:<5> but was:<4>
> [junit] junit.framework.AssertionFailedError: expected:<5> but was:<4>
> [junit] at 
> org.apache.cassandra.stress.generate.DistributionSequenceTest.setSeed(DistributionSequenceTest.java:111)
> [junit]
> [junit]
> [junit] Test 
> org.apache.cassandra.stress.generate.DistributionSequenceTest FAILED
> {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

cassandra git commit: Fix cassandra-stress startup failure

[bdeggleston]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 03f5997f9 -> 1db54a126


Fix cassandra-stress startup failure

patch by Jay Zhuang; reviewed by Blake Eggleston for CASSANDRA-14106


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

Branch: refs/heads/trunk
Commit: 1db54a1266a68d9c765c0fa248277635c4520f6d
Parents: 03f5997
Author: Jay Zhuang 
Authored: Mon Dec 11 23:11:21 2017 -0800
Committer: Blake Eggleston 
Committed: Tue Dec 19 16:23:07 2017 -0800

--
 CHANGES.txt |  1 +
 .../cassandra/stress/generate/Distribution.java |  4 +-
 .../generate/DistributionGaussianTest.java  | 77 
 3 files changed, 80 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1db54a12/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ee436e6..15954c8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Fix cassandra-stress startup failure (CASSANDRA-14106)
  * Remove initialDirectories from CFS (CASSANDRA-13928)
  * Fix trivial log format error (CASSANDRA-14015)
  * Allow sstabledump to do a json object per partition (CASSANDRA-13848)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1db54a12/tools/stress/src/org/apache/cassandra/stress/generate/Distribution.java
--
diff --git 
a/tools/stress/src/org/apache/cassandra/stress/generate/Distribution.java 
b/tools/stress/src/org/apache/cassandra/stress/generate/Distribution.java
index 30efd34..9d8ce1c 100644
--- a/tools/stress/src/org/apache/cassandra/stress/generate/Distribution.java
+++ b/tools/stress/src/org/apache/cassandra/stress/generate/Distribution.java
@@ -45,8 +45,8 @@ public abstract class Distribution implements Serializable
 public long average()
 {
 double sum = 0;
-double d = 0d;
-for (int count = 0; count < 50 ; count++)
+float d = 0;
+for (int count = 0; count < 51 ; count++)
 {
 sum += inverseCumProb(d);
 d += 0.02d;

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1db54a12/tools/stress/test/unit/org/apache/cassandra/stress/generate/DistributionGaussianTest.java
--
diff --git 
a/tools/stress/test/unit/org/apache/cassandra/stress/generate/DistributionGaussianTest.java
 
b/tools/stress/test/unit/org/apache/cassandra/stress/generate/DistributionGaussianTest.java
new file mode 100644
index 000..7f262e9
--- /dev/null
+++ 
b/tools/stress/test/unit/org/apache/cassandra/stress/generate/DistributionGaussianTest.java
@@ -0,0 +1,77 @@
+/*
+ * 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.stress.generate;
+
+import org.junit.Test;
+
+import org.apache.cassandra.stress.settings.OptionDistribution;
+
+import static java.lang.Math.toIntExact;
+import static org.junit.Assert.*;
+
+public class DistributionGaussianTest
+{
+@Test
+public void simpleGaussian()
+{
+Distribution dist = OptionDistribution.get("gaussian(1..10)").get();
+assertTrue(dist instanceof DistributionBoundApache);
+
+assertEquals(1, dist.minValue());
+assertEquals(10, dist.maxValue());
+assertEquals(5, dist.average());
+
+assertEquals(1, dist.inverseCumProb(0d));
+assertEquals(10, dist.inverseCumProb(1d));
+
+int testCount = 10;
+int[] results = new int[11];
+for (int i = 0; i < testCount; i++)
+{
+int val = toIntExact(dist.next());
+results[val]++;
+}
+
+// Increasing for the first half
+for (int i = toIntExact(dist.minValue()); i < dist.average(); i++)
+ 

cassandra git commit: Small tweak of new security language on attack surface.

[zznate]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 8764ef2da -> 03f5997f9


Small tweak of new security language on attack surface.


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

Branch: refs/heads/trunk
Commit: 03f5997f9c18f13fd0c18dcdbeeed82e912de494
Parents: 8764ef2
Author: Nate McCall 
Authored: Wed Dec 20 13:11:54 2017 +1300
Committer: Nate McCall 
Committed: Wed Dec 20 13:11:54 2017 +1300

--
 doc/source/operating/security.rst | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/03f5997f/doc/source/operating/security.rst
--
diff --git a/doc/source/operating/security.rst 
b/doc/source/operating/security.rst
index 212a25e..21245fd 100644
--- a/doc/source/operating/security.rst
+++ b/doc/source/operating/security.rst
@@ -26,12 +26,13 @@ There are three main components to the security features 
provided by Cassandra:
 
 By default, these features are disabled as Cassandra is configured to easily 
find and be found by other members of a
 cluster. In other words, an out-of-the-box Cassandra installation presents a 
large attack surface for a bad actor.
-Possible attack vectors include:
+Enabling authentication for clients using the binary protocol is not 
sufficient to protect a cluster. Malicious users
+able to access internode communication and JMX ports can still:
 
-- Crafted internode messages to insert users into authentication schema
-- Crafted internode messages to truncate or drop schema
-- Use of tools such as ``sstableloader`` to overwrite ``system_auth`` tables 
-- Attaching to the cluster directly to capture write traffic
+- Craft internode messages to insert users into authentication schema
+- Craft internode messages to truncate or drop schema
+- Use tools such as ``sstableloader`` to overwrite ``system_auth`` tables 
+- Attach to the cluster directly to capture write traffic
 
 Correct configuration of all three security components should negate theses 
vectors. Therefore, understanding Cassandra's
 security features is crucial to configuring your cluster to meet your security 
needs.


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

[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-13985:
-

I pushed up a branch with a different approach 
[here|https://github.com/bdeggleston/cassandra/tree/13985-v2], and some 
associated dtests 
[here|https://github.com/bdeggleston/cassandra-dtest/tree/13958-v2].

In this version, datacenter permissions are associated with a single user role, 
they're not inherited through the role hierarchy or anything. They're stored in 
their own table, but are administered through the existing CREATE/ALTER 
USER/ROLE statements. By default, a user has access to all dcs unless 
configured otherwise.


> Support restricting reads and writes to specific datacenters on a per user 
> basis
> 
>
> Key: CASSANDRA-13985
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13985
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 4.0
>
>
> There are a few use cases where it makes sense to restrict the operations a 
> given user can perform in specific data centers. The obvious use case is the 
> production/analytics datacenter configuration. You don’t want the production 
> user to be reading/or writing to the analytics datacenter, and you don’t want 
> the analytics user to be reading from the production datacenter.
> Although we expect users to get this right on that application level, we 
> should also be able to enforce this at the database level. The first approach 
> that comes to mind would be to support an optional DC parameter when granting 
> select and modify permissions to roles. Something like {{GRANT SELECT ON 
> some_keyspace TO that_user IN DC dc1}}, statements that omit the dc would 
> implicitly be granting permission to all dcs. However, I’m not married to 
> this approach.



--
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] [Issue Comment Deleted] (CASSANDRA-14130) nodetool compactionstats gets stuck

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-14130:
---
Comment: was deleted

(was: What version are you running [~hkroger] ? 
)

> nodetool compactionstats gets stuck
> ---
>
> Key: CASSANDRA-14130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14130
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
> Attachments: jstack.txt, nodetool_jstack.txt
>
>
> We have a server that works apparently quite normally but nodetool 
> compactionstats command hangs.
> For example "status" works fine
> {code}
> $ nodetool status
> {code}
> But "compactionstats" hangs 
> {code}
> $ nodetool compactionstats
> {code}
> Hanging also happens when calling using JMX:
> {code}
> Welcome to JMX terminal. Type "help" for available commands.
> $>open localhost:7199
> #Connection to localhost:7199 is opened
> $>bean 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName
> #bean is set to 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName
> $>get Value
> #mbean = 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName:
> {code}
> What could be the problem?



--
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-14130) nodetool compactionstats gets stuck

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-14130:


What version are you running [~hkroger] ? 


> nodetool compactionstats gets stuck
> ---
>
> Key: CASSANDRA-14130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14130
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
> Attachments: jstack.txt, nodetool_jstack.txt
>
>
> We have a server that works apparently quite normally but nodetool 
> compactionstats command hangs.
> For example "status" works fine
> {code}
> $ nodetool status
> {code}
> But "compactionstats" hangs 
> {code}
> $ nodetool compactionstats
> {code}
> Hanging also happens when calling using JMX:
> {code}
> Welcome to JMX terminal. Type "help" for available commands.
> $>open localhost:7199
> #Connection to localhost:7199 is opened
> $>bean 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName
> #bean is set to 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName
> $>get Value
> #mbean = 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName:
> {code}
> What could be the problem?



--
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-14087) NPE when CAS encounters empty frozen collection

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-14087:

Reproduced In: 3.11.1, 3.11.0, 3.0.0  (was: 3.0.0, 3.11.0, 3.11.1)
 Reviewer: Blake Eggleston

> NPE when CAS encounters empty frozen collection
> ---
>
> Key: CASSANDRA-14087
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14087
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jens Bannmann
>Assignee: Kurt Greaves
> Fix For: 3.0.16, 3.11.2
>
>
> When a compare-and-set operation specifying an equality criterion with a 
> non-{{null}} value encounters an empty collection ({{null}} cell), the server 
> throws a {{NullPointerException}} and the query fails.
> This does not happen for non-frozen collections.
> There's a self-contained test case at 
> [github|https://github.com/incub8/cassandra-npe-in-cas].
> The stack trace for 3.11.0 is:
> {code}
> ERROR [Native-Transport-Requests-1] 2017-11-27 12:59:26,924 
> QueryMessage.java:129 - Unexpected error during query
> java.lang.NullPointerException: null
> at 
> org.apache.cassandra.cql3.ColumnCondition$CollectionBound.appliesTo(ColumnCondition.java:546)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest$ColumnsConditions.appliesTo(CQL3CasRequest.java:324)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.appliesTo(CQL3CasRequest.java:210)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:265) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:441)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:416)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:217)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:248) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:233) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_151]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.0.jar:3.11.0]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> {code}



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

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

[jira] [Updated] (CASSANDRA-14106) utest failed: DistributionSequenceTest.setSeed() and simpleSequence()

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-14106:

Reviewer: Blake Eggleston

> utest failed: DistributionSequenceTest.setSeed() and simpleSequence()
> -
>
> Key: CASSANDRA-14106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14106
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> To reproduce:
> {noformat}
> $ ant stress-test -Dtest.name=DistributionSequenceTest
> {noformat}
> {noformat}
> stress-test:
> [junit] Testsuite: 
> org.apache.cassandra.stress.generate.DistributionSequenceTest
> [junit] Testsuite: 
> org.apache.cassandra.stress.generate.DistributionSequenceTest Tests run: 4, 
> Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.08 sec
> [junit]
> [junit] Testcase: 
> simpleSequence(org.apache.cassandra.stress.generate.DistributionSequenceTest):
> FAILED
> [junit] expected:<5> but was:<4>
> [junit] junit.framework.AssertionFailedError: expected:<5> but was:<4>
> [junit] at 
> org.apache.cassandra.stress.generate.DistributionSequenceTest.simpleSequence(DistributionSequenceTest.java:37)
> [junit]
> [junit]
> [junit] Testcase: 
> setSeed(org.apache.cassandra.stress.generate.DistributionSequenceTest):   
> FAILED
> [junit] expected:<5> but was:<4>
> [junit] junit.framework.AssertionFailedError: expected:<5> but was:<4>
> [junit] at 
> org.apache.cassandra.stress.generate.DistributionSequenceTest.setSeed(DistributionSequenceTest.java:111)
> [junit]
> [junit]
> [junit] Test 
> org.apache.cassandra.stress.generate.DistributionSequenceTest FAILED
> {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-14130) nodetool compactionstats gets stuck

[JIRA]

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

Hannu Kröger commented on CASSANDRA-14130:
--

It might be related to this: 
https://issues.apache.org/jira/browse/CASSANDRA-13948

> nodetool compactionstats gets stuck
> ---
>
> Key: CASSANDRA-14130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14130
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
> Attachments: jstack.txt, nodetool_jstack.txt
>
>
> We have a server that works apparently quite normally but nodetool 
> compactionstats command hangs.
> For example "status" works fine
> {code}
> $ nodetool status
> {code}
> But "compactionstats" hangs 
> {code}
> $ nodetool compactionstats
> {code}
> Hanging also happens when calling using JMX:
> {code}
> Welcome to JMX terminal. Type "help" for available commands.
> $>open localhost:7199
> #Connection to localhost:7199 is opened
> $>bean 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName
> #bean is set to 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName
> $>get Value
> #mbean = 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName:
> {code}
> What could be the problem?



--
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-13313) Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13313:


Reopening, patch coming soon.


> Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0
> --
>
> Key: CASSANDRA-13313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13313
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
>
> Before 3.0 we used sstable ancestors to figure out if an sstable was left 
> over after a compaction. In 3.0 the ancestors are ignored and instead we use 
> LogTransaction files to figure it out. 3.0 should still clean up 2.1/2.2 
> compaction leftovers using the on-disk sstable ancestors when available.



--
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-13313) Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa reopened CASSANDRA-13313:


> Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0
> --
>
> Key: CASSANDRA-13313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13313
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
>
> Before 3.0 we used sstable ancestors to figure out if an sstable was left 
> over after a compaction. In 3.0 the ancestors are ignored and instead we use 
> LogTransaction files to figure it out. 3.0 should still clean up 2.1/2.2 
> compaction leftovers using the on-disk sstable ancestors when available.



--
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-8527) Account for range tombstones wherever we account for tombstones

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-8527:
---

{quote}
The way the code is architected, I don't see a way of returning the number of 
range tombstones without pretty deep changes. 
Counting the number of deleted rows is already very interesting and would not 
require dangerous modifications.
{quote}

OK, we can do it as a follow up.

{quote}
But if we can't do this in a new major version, then when is the appropriate 
time ? 
A first step could be to introduce a flag and an additional warning.
It would be something like :
{quote}

I'm not saying we shouldn't do it in this version.  I think we should kick this 
discussion into the dev ML to get some more eyes on it.  As far as I can tell, 
the options are

1. Keep the old behavior
2. Keep new
3. Config for picking
4. Separate config options for both.  

{quote}
Do you think adding Mockito to the list of dependencies is reasonable/wanted ?
{quote}

I have no objections, and I think it would help make the codebase more 
testable.  


> Account for range tombstones wherever we account for tombstones
> ---
>
> Key: CASSANDRA-8527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8527
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Alexander Dejanovski
> Fix For: 4.x
>
> Attachments: CASSANDRA-8527.diff
>
>
> As discussed in CASSANDRA-8477, we should make sure the tombstone thresholds 
> also apply to range tombstones, since they poses the same problems than cell 
> tombstones.



--
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-14130) nodetool compactionstats gets stuck

[JIRA]

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

Hannu Kröger commented on CASSANDRA-14130:
--

When looking at the jstack and code, it seems like it is some sort of a race 
condition with readLock.

> nodetool compactionstats gets stuck
> ---
>
> Key: CASSANDRA-14130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14130
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
> Attachments: jstack.txt, nodetool_jstack.txt
>
>
> We have a server that works apparently quite normally but nodetool 
> compactionstats command hangs.
> For example "status" works fine
> {code}
> $ nodetool status
> {code}
> But "compactionstats" hangs 
> {code}
> $ nodetool compactionstats
> {code}
> Hanging also happens when calling using JMX:
> {code}
> Welcome to JMX terminal. Type "help" for available commands.
> $>open localhost:7199
> #Connection to localhost:7199 is opened
> $>bean 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName
> #bean is set to 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName
> $>get Value
> #mbean = 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName:
> {code}
> What could be the problem?



--
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-builds git commit: Fix novnode script

[jjirsa]

Repository: cassandra-builds
Updated Branches:
  refs/heads/master 6cb397bb6 -> 99474cfea


Fix novnode script


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

Branch: refs/heads/master
Commit: 99474cfea95394b1ca7a21c5ff21f64eaa4b1c42
Parents: 6cb397b
Author: Jeff Jirsa 
Authored: Tue Dec 19 09:21:05 2017 -0800
Committer: Jeff Jirsa 
Committed: Tue Dec 19 09:21:05 2017 -0800

--
 build-scripts/cassandra-dtest.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra-builds/blob/99474cfe/build-scripts/cassandra-dtest.sh
--
diff --git a/build-scripts/cassandra-dtest.sh b/build-scripts/cassandra-dtest.sh
index 63dd0d1..7867033 100755
--- a/build-scripts/cassandra-dtest.sh
+++ b/build-scripts/cassandra-dtest.sh
@@ -53,7 +53,7 @@ if [ "${DTEST_TARGET}" = "dtest" ]; then
 ./run_dtests.py --vnodes true --nose-options="--verbosity=3 --with-xunit 
--nocapture --attr=!resource-intensive" | tee -a ${WORKSPACE}/test_stdout.txt
 elif [ "${DTEST_TARGET}" = "dtest-novnode" ]; then
 export DISABLE_VNODES="true"
-./run_dtests.py --vnodes true --nose-options="--verbosity=3 --with-xunit 
--nocapture --attr=!resource-intensive" | tee -a ${WORKSPACE}/test_stdout.txt
+./run_dtests.py --vnodes false --nose-options="--verbosity=3 --with-xunit 
--nocapture --attr=!resource-intensive" | tee -a ${WORKSPACE}/test_stdout.txt
 elif [ "${DTEST_TARGET}" = "dtest-offheap" ]; then
 export OFFHEAP_MEMTABLES="true"
 ./run_dtests.py --vnodes true --nose-options="--verbosity=3 --with-xunit 
--nocapture --attr=!resource-intensive" | tee -a ${WORKSPACE}/test_stdout.txt


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

[jira] [Commented] (CASSANDRA-8527) Account for range tombstones wherever we account for tombstones

[Alexander Dejanovski (JIRA)]

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

Alexander Dejanovski commented on CASSANDRA-8527:
-

[~rustyrazorblade], as much as I would like to count the range tombstones, my 
understanding of the code shows that they are already merged with the rows 
before being returned to the ReadCommand subclass in charge.

You can see here that this is done on purpose because the code path responsible 
for reading a partition from memtables and sstables can be used from different 
places (like compaction for example) : 
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java#L563-L578

The way the code is architected, I don't see a way of returning the number of 
range tombstones without pretty deep changes. 
Counting the number of deleted rows is already very interesting and would not 
require dangerous modifications.

Wether or not to count such rows in the failure threshold is clearly debatable 
as it would indeed break existing (but probably poorly performing) queries.
But if we can't do this in a new major version, then when is the appropriate 
time ? 
A first step could be to introduce a flag and an additional warning.
It would be something like : 
{noformat}
include_deleted_rows_in_tombstone_failure_threshold: false
{noformat}

If set to false (which would be the default at first) then we would issue a 
warning that the query would probably fail in future versions or if the flag 
was set to true.
If set to true, then the count of deleted rows would be summed to the tombstone 
count to fail queries.

Then we could change this (or not) to false in future releases. I seem to 
recall that an similar thing was done for cross_node_timeout and it is still 
set to false by default to avoid timeouts when nodes aren't properly in sync on 
time.

I've taken a look at how I could add unit tests for that code, and I would need 
to hook on the table metrics of the ColumnFamilyStore object. The simplest way 
of doing this without running the whole stack would be to use a Mockito spy. 
Do you think adding Mockito to the list of dependencies is reasonable/wanted ?

> Account for range tombstones wherever we account for tombstones
> ---
>
> Key: CASSANDRA-8527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8527
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Alexander Dejanovski
> Fix For: 4.x
>
> Attachments: CASSANDRA-8527.diff
>
>
> As discussed in CASSANDRA-8477, we should make sure the tombstone thresholds 
> also apply to range tombstones, since they poses the same problems than cell 
> tombstones.



--
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-14131) Full FreeBSD support

[Konrad Jopek (JIRA)]

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

Konrad Jopek updated CASSANDRA-14131:
-
Description: 
FreeBSD had problems with Cassandra (CASSANDRA-8325). Attached patch is 
modified version of untested_2.2.4-src.patch from mentioned task and also adds 
native libraries support for FreeBSD.

TODO: Add KQueue support in the same manner as Epoll.

  was:
FreeBSD had problems with Cassandra (CASSANDRA-8325). Attached patch is direct 
reimplementation patch from mentioned task and also adds native libraries 
support for FreeBSD.

TODO: Add KQueue support in the same manner as Epoll.


> Full FreeBSD support
> 
>
> Key: CASSANDRA-14131
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14131
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination
>Reporter: Konrad Jopek
> Attachments: cassandra-freebsd.patch
>
>
> FreeBSD had problems with Cassandra (CASSANDRA-8325). Attached patch is 
> modified version of untested_2.2.4-src.patch from mentioned task and also 
> adds native libraries support for FreeBSD.
> TODO: Add KQueue support in the same manner as Epoll.



--
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-14131) Full FreeBSD support

[Konrad Jopek (JIRA)]

Konrad Jopek created CASSANDRA-14131:


 Summary: Full FreeBSD support
 Key: CASSANDRA-14131
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14131
 Project: Cassandra
  Issue Type: Improvement
  Components: Coordination
Reporter: Konrad Jopek
 Attachments: cassandra-freebsd.patch

FreeBSD had problems with Cassandra (CASSANDRA-8325). Attached patch is direct 
reimplementation patch from mentioned task and also adds native libraries 
support for FreeBSD.

TODO: Add KQueue support in the same manner as Epoll.



--
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-14130) nodetool compactionstats gets stuck

[JIRA]

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

Hannu Kröger updated CASSANDRA-14130:
-
Attachment: jstack.txt
nodetool_jstack.txt

> nodetool compactionstats gets stuck
> ---
>
> Key: CASSANDRA-14130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14130
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
> Attachments: jstack.txt, nodetool_jstack.txt
>
>
> We have a server that works apparently quite normally but nodetool 
> compactionstats command hangs.
> For example "status" works fine
> {code}
> $ nodetool status
> {code}
> But "compactionstats" hangs 
> {code}
> $ nodetool compactionstats
> {code}
> Hanging also happens when calling using JMX:
> {code}
> Welcome to JMX terminal. Type "help" for available commands.
> $>open localhost:7199
> #Connection to localhost:7199 is opened
> $>bean 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName
> #bean is set to 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName
> $>get Value
> #mbean = 
> org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName:
> {code}
> What could be the problem?



--
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-14065) Docs: Fix page width exceeding the viewport

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-14065:
---
Attachment: 0001-Docs-optimize-css-layouting.patch
0002-site_svn-css.diff
0003-site_svn-fixnavigation.diff

I've done some css tweaking to optimize the docs layouts. I'd also like to get 
rid of the scrolling behaviour of the navigation, which is messing up the 
dynamic bootstrap layouting (and is just annoying anyways). You can apply the 
diffs using {{patch -p0 -i }}. 





> Docs: Fix page width exceeding the viewport
> ---
>
> Key: CASSANDRA-14065
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14065
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Stefan Podkowinski
> Fix For: 4.x
>
> Attachments: 0001-Docs-optimize-css-layouting.patch, 
> 0002-site_svn-css.diff, 0003-site_svn-fixnavigation.diff, 14065-trunk.patch
>
>
> Ticket for [#175|https://github.com/apache/cassandra/pull/175] / 
> [#176|https://github.com/apache/cassandra/pull/176].
> The layout seems to adapt more natural after applying the patch with less 
> overlapping content. Seems to fix a real issue with our template.
> However, I'm not really sure about the extra.css changes, as the compile 
> website (build via jekyll) doesn't seem to reference the css file anywhere..



--
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-14130) nodetool compactionstats gets stuck

[JIRA]

Hannu Kröger created CASSANDRA-14130:


 Summary: nodetool compactionstats gets stuck
 Key: CASSANDRA-14130
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14130
 Project: Cassandra
  Issue Type: Bug
Reporter: Hannu Kröger


We have a server that works apparently quite normally but nodetool 
compactionstats command hangs.

For example "status" works fine
{code}
$ nodetool status
{code}

But "compactionstats" hangs 
{code}
$ nodetool compactionstats
{code}

Hanging also happens when calling using JMX:

{code}
Welcome to JMX terminal. Type "help" for available commands.
$>open localhost:7199
#Connection to localhost:7199 is opened
$>bean org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName
#bean is set to 
org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName
$>get Value
#mbean = 
org.apache.cassandra.metrics:type=Compaction,name=PendingTasksByTableName:
{code}

What could be the problem?



--
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-12971) Add CAS option to WRITE test to stress tool

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-12971:
---
Resolution: Duplicate
Status: Resolved  (was: Patch Available)

> Add CAS option to WRITE test to stress tool
> ---
>
> Key: CASSANDRA-12971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12971
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Stress, Tools
>Reporter: Vladimir Yudovin
>Assignee: Vladimir Yudovin
> Attachments: stress-cass.patch
>
>
> If -cas option is present each UPDATE is performed with true IF condition, 
> thus data is inserted anyway.
> It's implemented, if it's needed I proceed with the patch.



--
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-14066) unittest failed: CommitLogSegmentManagerCDCTest.testReplayLogic

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-14066:
---
Reviewer: Stefan Podkowinski

> unittest failed: CommitLogSegmentManagerCDCTest.testReplayLogic
> ---
>
> Key: CASSANDRA-14066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14066
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> To reproduce:
> {noformat}
> $ ant test-cdc -Dtest.name=CommitLogSegmentManagerCDCTest
> {noformat}
> Error:
> {noformat}
> [junit] Testcase: 
> testReplayLogic(org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest)-cdc:
> FAILED
> [junit] Missing old CDCIndexData in new set after replay: 
> CommitLog-7-1511301220821_cdc.idx,3497190
> [junit] List of CDCIndexData in new set of indexes after replay:
> [junit]CommitLog-7-1511301220822_cdc.idx,3509214
> [junit]CommitLog-7-1511301220823_cdc.idx,100
> [junit]
> [junit] junit.framework.AssertionFailedError: Missing old CDCIndexData in 
> new set after replay: CommitLog-7-1511301220821_cdc.idx,3497190
> [junit] List of CDCIndexData in new set of indexes after replay:
> [junit]CommitLog-7-1511301220822_cdc.idx,3509214
> [junit]CommitLog-7-1511301220823_cdc.idx,100
> [junit]
> [junit] at 
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic(CommitLogSegmentManagerCDCTest.java:345)
> [junit]
> [junit]
> [junit] Test 
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest FAILED
> {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-14104) Index target doesn't correctly recognise non-UTF column names after COMPACT STORAGE drop

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-14104:
-

Committed to 3.0 as 
[0521f8dc5d5e05c0530726e9549fa2481726a818|https://github.com/apache/cassandra/commit/0521f8dc5d5e05c0530726e9549fa2481726a818]
 and merged up to 
[3.11|https://github.com/apache/cassandra/commit/adc32ac836e90b8c4503030feb76ce031998ad80]
 and 
[trunk|https://github.com/apache/cassandra/commit/8764ef2da367fac64adad0821a34e6fa15da13c6].

> Index target doesn't correctly recognise non-UTF column names after COMPACT 
> STORAGE drop
> 
>
> Key: CASSANDRA-14104
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14104
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
> Attachments: ifesdjeen-14104-3.0-dtest.png, 
> ifesdjeen-14104-3.0-testall.png, ifesdjeen-14104-3.11-dtest.png, 
> ifesdjeen-14104-3.11-testall.png, ifesdjeen-14104-trunk-dtest.png, 
> ifesdjeen-14104-trunk-testall.png
>
>
> Creating a compact storage table with dynamic composite type, then running 
> {{ALTER TALBE ... DROP COMPACT STORAGE}} and then restarting the node will 
> crash Cassandra node, since the Index Target is fetched using hashmap / 
> strict equality. We need to fall back to linear search when index target 
> can't be found (which should not be happening often).



--
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-14104) Index target doesn't correctly recognise non-UTF column names after COMPACT STORAGE drop

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-14104:

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

> Index target doesn't correctly recognise non-UTF column names after COMPACT 
> STORAGE drop
> 
>
> Key: CASSANDRA-14104
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14104
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
> Attachments: ifesdjeen-14104-3.0-dtest.png, 
> ifesdjeen-14104-3.0-testall.png, ifesdjeen-14104-3.11-dtest.png, 
> ifesdjeen-14104-3.11-testall.png, ifesdjeen-14104-trunk-dtest.png, 
> ifesdjeen-14104-trunk-testall.png
>
>
> Creating a compact storage table with dynamic composite type, then running 
> {{ALTER TALBE ... DROP COMPACT STORAGE}} and then restarting the node will 
> crash Cassandra node, since the Index Target is fetched using hashmap / 
> strict equality. We need to fall back to linear search when index target 
> can't be found (which should not be happening often).



--
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/6] cassandra git commit: Fix index target computation for dense composite tables with dropped compact storage

[ifesdjeen]

Fix index target computation for dense composite tables with dropped compact 
storage

Patch by Alex Petrov; reviewed by Zhao Yang for CASSANDRA-14104.

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

Branch: refs/heads/cassandra-3.11
Commit: 0521f8dc5d5e05c0530726e9549fa2481726a818
Parents: 5050aa3
Author: Alex Petrov 
Authored: Mon Dec 11 18:56:40 2017 +0100
Committer: Alex Petrov 
Committed: Tue Dec 19 09:55:00 2017 +0100

--
 CHANGES.txt |   1 +
 .../index/internal/CassandraIndex.java  |  33 --
 .../DropCompactStorageThriftTest.java   | 116 +++
 3 files changed, 139 insertions(+), 11 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0521f8dc/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0574893..7746c73 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.16
+ * Fix index target computation for dense composite tables with dropped 
compact storage (CASSANDRA-14104)
  * Improve commit log chain marker updating (CASSANDRA-14108)
  * Extra range tombstone bound creates double rows (CASSANDRA-14008)
  * Fix SStable ordering by max timestamp in SinglePartitionReadCommand 
(CASSANDRA-14010)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0521f8dc/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
--
diff --git a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java 
b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
index 5caeefa..3211fe9 100644
--- a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
+++ b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
@@ -52,6 +52,7 @@ import org.apache.cassandra.db.partitions.PartitionIterator;
 import org.apache.cassandra.db.partitions.PartitionUpdate;
 import org.apache.cassandra.db.rows.*;
 import org.apache.cassandra.dht.LocalPartitioner;
+import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.exceptions.InvalidRequestException;
 import org.apache.cassandra.index.Index;
 import org.apache.cassandra.index.IndexRegistry;
@@ -790,13 +791,20 @@ public abstract class CassandraIndex implements Index
 return getFunctions(indexMetadata, parseTarget(baseCfs.metadata, 
indexMetadata)).newIndexInstance(baseCfs, indexMetadata);
 }
 
-// Public because it's also used to convert index metadata into a 
thrift-compatible format
-public static Pair 
parseTarget(CFMetaData cfm,
-   
IndexMetadata indexDef)
+public static Pair 
parseTarget(CFMetaData cfm, IndexMetadata indexDef)
 {
 String target = indexDef.options.get("target");
 assert target != null : String.format("No target definition found for 
index %s", indexDef.name);
+Pair result = parseTarget(cfm, 
target);
+if (result == null)
+throw new ConfigurationException(String.format("Unable to parse 
targets for index %s (%s)", indexDef.name, target));
+return result;
+}
 
+// Public because it's also used to convert index metadata into a 
thrift-compatible format
+public static Pair 
parseTarget(CFMetaData cfm,
+   String 
target)
+{
 // if the regex matches then the target is in the form "keys(foo)", 
"entries(bar)" etc
 // if not, then it must be a simple column name and implictly its type 
is VALUES
 Matcher matcher = TARGET_REGEX.matcher(target);
@@ -826,15 +834,18 @@ public abstract class CassandraIndex implements Index
 }
 
 // if it's not a CQL table, we can't assume that the column name is 
utf8, so
-// in that case we have to do a linear scan of the cfm's columns to 
get the matching one
-if (cfm.isCQLTable())
-return Pair.create(cfm.getColumnDefinition(new 
ColumnIdentifier(columnName, true)), targetType);
-else
-for (ColumnDefinition column : cfm.allColumns())
-if (column.name.toString().equals(columnName))
-return Pair.create(column, targetType);
+// in that case we have to do a linear scan of the cfm's columns to 
get the matching one.
+

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

[ifesdjeen]

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

Branch: refs/heads/trunk
Commit: adc32ac836e90b8c4503030feb76ce031998ad80
Parents: 95c8aef 0521f8d
Author: Alex Petrov 
Authored: Tue Dec 19 10:55:50 2017 +0100
Committer: Alex Petrov 
Committed: Tue Dec 19 10:55:50 2017 +0100

--
 CHANGES.txt |   1 +
 .../apache/cassandra/index/TargetParser.java|  17 +--
 .../DropCompactStorageThriftTest.java   | 116 +++
 3 files changed, 127 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/adc32ac8/CHANGES.txt
--
diff --cc CHANGES.txt
index 3f15c5d,7746c73..5a1b891
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,15 -1,5 +1,16 @@@
 -3.0.16
 +3.11.2
 + * Prevent continuous schema exchange between 3.0 and 3.11 nodes 
(CASSANDRA-14109)
 + * Fix imbalanced disks when replacing node with same address with JBOD 
(CASSANDRA-14084)
 + * Reload compaction strategies when disk boundaries are invalidated 
(CASSANDRA-13948)
 + * Remove OpenJDK log warning (CASSANDRA-13916)
 + * Prevent compaction strategies from looping indefinitely (CASSANDRA-14079)
 + * Cache disk boundaries (CASSANDRA-13215)
 + * Add asm jar to build.xml for maven builds (CASSANDRA-11193)
 + * Round buffer size to powers of 2 for the chunk cache (CASSANDRA-13897)
 + * Update jackson JSON jars (CASSANDRA-13949)
 + * Avoid locks when checking LCS fanout and if we should defrag 
(CASSANDRA-13930)
 +Merged from 3.0:
+  * Fix index target computation for dense composite tables with dropped 
compact storage (CASSANDRA-14104)
   * Improve commit log chain marker updating (CASSANDRA-14108)
   * Extra range tombstone bound creates double rows (CASSANDRA-14008)
   * Fix SStable ordering by max timestamp in SinglePartitionReadCommand 
(CASSANDRA-14010)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/adc32ac8/src/java/org/apache/cassandra/index/TargetParser.java
--
diff --cc src/java/org/apache/cassandra/index/TargetParser.java
index 849ad16,000..96d03af
mode 100644,00..100644
--- a/src/java/org/apache/cassandra/index/TargetParser.java
+++ b/src/java/org/apache/cassandra/index/TargetParser.java
@@@ -1,90 -1,0 +1,93 @@@
 +/*
 + * 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.index;
 +
 +import java.util.regex.Matcher;
 +import java.util.regex.Pattern;
 +
 +import org.apache.commons.lang3.StringUtils;
 +
 +import org.apache.cassandra.config.CFMetaData;
 +import org.apache.cassandra.config.ColumnDefinition;
 +import org.apache.cassandra.cql3.ColumnIdentifier;
 +import org.apache.cassandra.cql3.statements.IndexTarget;
 +import org.apache.cassandra.exceptions.ConfigurationException;
 +import org.apache.cassandra.schema.IndexMetadata;
 +import org.apache.cassandra.utils.Pair;
 +
 +public class TargetParser
 +{
 +private static final Pattern TARGET_REGEX = 
Pattern.compile("^(keys|entries|values|full)\\((.+)\\)$");
 +private static final Pattern TWO_QUOTES = Pattern.compile("\"\"");
 +private static final String QUOTE = "\"";
 +
 +public static Pair parse(CFMetaData 
cfm, IndexMetadata indexDef)
 +{
 +String target = indexDef.options.get("target");
 +assert target != null : String.format("No target definition found for 
index %s", indexDef.name);
 +Pair result = parse(cfm, target);
 +if (result == null)
 +throw new ConfigurationException(String.format("Unable to parse 
targets for index %s (%s)", indexDef.name, target));
 +return result;
 

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

[ifesdjeen]

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

Branch: refs/heads/cassandra-3.11
Commit: adc32ac836e90b8c4503030feb76ce031998ad80
Parents: 95c8aef 0521f8d
Author: Alex Petrov 
Authored: Tue Dec 19 10:55:50 2017 +0100
Committer: Alex Petrov 
Committed: Tue Dec 19 10:55:50 2017 +0100

--
 CHANGES.txt |   1 +
 .../apache/cassandra/index/TargetParser.java|  17 +--
 .../DropCompactStorageThriftTest.java   | 116 +++
 3 files changed, 127 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/adc32ac8/CHANGES.txt
--
diff --cc CHANGES.txt
index 3f15c5d,7746c73..5a1b891
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,15 -1,5 +1,16 @@@
 -3.0.16
 +3.11.2
 + * Prevent continuous schema exchange between 3.0 and 3.11 nodes 
(CASSANDRA-14109)
 + * Fix imbalanced disks when replacing node with same address with JBOD 
(CASSANDRA-14084)
 + * Reload compaction strategies when disk boundaries are invalidated 
(CASSANDRA-13948)
 + * Remove OpenJDK log warning (CASSANDRA-13916)
 + * Prevent compaction strategies from looping indefinitely (CASSANDRA-14079)
 + * Cache disk boundaries (CASSANDRA-13215)
 + * Add asm jar to build.xml for maven builds (CASSANDRA-11193)
 + * Round buffer size to powers of 2 for the chunk cache (CASSANDRA-13897)
 + * Update jackson JSON jars (CASSANDRA-13949)
 + * Avoid locks when checking LCS fanout and if we should defrag 
(CASSANDRA-13930)
 +Merged from 3.0:
+  * Fix index target computation for dense composite tables with dropped 
compact storage (CASSANDRA-14104)
   * Improve commit log chain marker updating (CASSANDRA-14108)
   * Extra range tombstone bound creates double rows (CASSANDRA-14008)
   * Fix SStable ordering by max timestamp in SinglePartitionReadCommand 
(CASSANDRA-14010)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/adc32ac8/src/java/org/apache/cassandra/index/TargetParser.java
--
diff --cc src/java/org/apache/cassandra/index/TargetParser.java
index 849ad16,000..96d03af
mode 100644,00..100644
--- a/src/java/org/apache/cassandra/index/TargetParser.java
+++ b/src/java/org/apache/cassandra/index/TargetParser.java
@@@ -1,90 -1,0 +1,93 @@@
 +/*
 + * 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.index;
 +
 +import java.util.regex.Matcher;
 +import java.util.regex.Pattern;
 +
 +import org.apache.commons.lang3.StringUtils;
 +
 +import org.apache.cassandra.config.CFMetaData;
 +import org.apache.cassandra.config.ColumnDefinition;
 +import org.apache.cassandra.cql3.ColumnIdentifier;
 +import org.apache.cassandra.cql3.statements.IndexTarget;
 +import org.apache.cassandra.exceptions.ConfigurationException;
 +import org.apache.cassandra.schema.IndexMetadata;
 +import org.apache.cassandra.utils.Pair;
 +
 +public class TargetParser
 +{
 +private static final Pattern TARGET_REGEX = 
Pattern.compile("^(keys|entries|values|full)\\((.+)\\)$");
 +private static final Pattern TWO_QUOTES = Pattern.compile("\"\"");
 +private static final String QUOTE = "\"";
 +
 +public static Pair parse(CFMetaData 
cfm, IndexMetadata indexDef)
 +{
 +String target = indexDef.options.get("target");
 +assert target != null : String.format("No target definition found for 
index %s", indexDef.name);
 +Pair result = parse(cfm, target);
 +if (result == null)
 +throw new ConfigurationException(String.format("Unable to parse 
targets for index %s (%s)", indexDef.name, target));
 +return 

[3/6] cassandra git commit: Fix index target computation for dense composite tables with dropped compact storage

[ifesdjeen]

Fix index target computation for dense composite tables with dropped compact 
storage

Patch by Alex Petrov; reviewed by Zhao Yang for CASSANDRA-14104.

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

Branch: refs/heads/trunk
Commit: 0521f8dc5d5e05c0530726e9549fa2481726a818
Parents: 5050aa3
Author: Alex Petrov 
Authored: Mon Dec 11 18:56:40 2017 +0100
Committer: Alex Petrov 
Committed: Tue Dec 19 09:55:00 2017 +0100

--
 CHANGES.txt |   1 +
 .../index/internal/CassandraIndex.java  |  33 --
 .../DropCompactStorageThriftTest.java   | 116 +++
 3 files changed, 139 insertions(+), 11 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0521f8dc/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0574893..7746c73 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.16
+ * Fix index target computation for dense composite tables with dropped 
compact storage (CASSANDRA-14104)
  * Improve commit log chain marker updating (CASSANDRA-14108)
  * Extra range tombstone bound creates double rows (CASSANDRA-14008)
  * Fix SStable ordering by max timestamp in SinglePartitionReadCommand 
(CASSANDRA-14010)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0521f8dc/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
--
diff --git a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java 
b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
index 5caeefa..3211fe9 100644
--- a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
+++ b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
@@ -52,6 +52,7 @@ import org.apache.cassandra.db.partitions.PartitionIterator;
 import org.apache.cassandra.db.partitions.PartitionUpdate;
 import org.apache.cassandra.db.rows.*;
 import org.apache.cassandra.dht.LocalPartitioner;
+import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.exceptions.InvalidRequestException;
 import org.apache.cassandra.index.Index;
 import org.apache.cassandra.index.IndexRegistry;
@@ -790,13 +791,20 @@ public abstract class CassandraIndex implements Index
 return getFunctions(indexMetadata, parseTarget(baseCfs.metadata, 
indexMetadata)).newIndexInstance(baseCfs, indexMetadata);
 }
 
-// Public because it's also used to convert index metadata into a 
thrift-compatible format
-public static Pair 
parseTarget(CFMetaData cfm,
-   
IndexMetadata indexDef)
+public static Pair 
parseTarget(CFMetaData cfm, IndexMetadata indexDef)
 {
 String target = indexDef.options.get("target");
 assert target != null : String.format("No target definition found for 
index %s", indexDef.name);
+Pair result = parseTarget(cfm, 
target);
+if (result == null)
+throw new ConfigurationException(String.format("Unable to parse 
targets for index %s (%s)", indexDef.name, target));
+return result;
+}
 
+// Public because it's also used to convert index metadata into a 
thrift-compatible format
+public static Pair 
parseTarget(CFMetaData cfm,
+   String 
target)
+{
 // if the regex matches then the target is in the form "keys(foo)", 
"entries(bar)" etc
 // if not, then it must be a simple column name and implictly its type 
is VALUES
 Matcher matcher = TARGET_REGEX.matcher(target);
@@ -826,15 +834,18 @@ public abstract class CassandraIndex implements Index
 }
 
 // if it's not a CQL table, we can't assume that the column name is 
utf8, so
-// in that case we have to do a linear scan of the cfm's columns to 
get the matching one
-if (cfm.isCQLTable())
-return Pair.create(cfm.getColumnDefinition(new 
ColumnIdentifier(columnName, true)), targetType);
-else
-for (ColumnDefinition column : cfm.allColumns())
-if (column.name.toString().equals(columnName))
-return Pair.create(column, targetType);
+// in that case we have to do a linear scan of the cfm's columns to 
get the matching one.
+// After 

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

[ifesdjeen]

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

Branch: refs/heads/trunk
Commit: 8764ef2da367fac64adad0821a34e6fa15da13c6
Parents: 6cd4009 adc32ac
Author: Alex Petrov 
Authored: Tue Dec 19 10:59:23 2017 +0100
Committer: Alex Petrov 
Committed: Tue Dec 19 10:59:23 2017 +0100

--
 CHANGES.txt|  1 +
 .../org/apache/cassandra/index/TargetParser.java   | 17 ++---
 2 files changed, 11 insertions(+), 7 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8764ef2d/src/java/org/apache/cassandra/index/TargetParser.java
--
diff --cc src/java/org/apache/cassandra/index/TargetParser.java
index ec25259,96d03af..bc679f2
--- a/src/java/org/apache/cassandra/index/TargetParser.java
+++ b/src/java/org/apache/cassandra/index/TargetParser.java
@@@ -77,13 -77,16 +77,16 @@@ public class TargetParse
  }
  
  // if it's not a CQL table, we can't assume that the column name is 
utf8, so
- // in that case we have to do a linear scan of the table's columns to 
get the matching one
- if (metadata.isCQLTable())
- return Pair.create(metadata.getColumn(new 
ColumnIdentifier(columnName, true)), targetType);
- else
- for (ColumnMetadata column : metadata.columns())
- if (column.name.toString().equals(columnName))
- return Pair.create(column, targetType);
+ // in that case we have to do a linear scan of the cfm's columns to 
get the matching one.
+ // After dropping compact storage (see CASSANDRA-10857), we can't 
distinguish between the
+ // former compact/thrift table, so we have to fall back to linear 
scan in both cases.
 -ColumnDefinition cd = cfm.getColumnDefinition(new 
ColumnIdentifier(columnName, true));
++ColumnMetadata cd = metadata.getColumn(new 
ColumnIdentifier(columnName, true));
+ if (cd != null)
+ return Pair.create(cd, targetType);
+ 
 -for (ColumnDefinition column : cfm.allColumns())
++for (ColumnMetadata column : metadata.columns())
+ if (column.name.toString().equals(columnName))
+ return Pair.create(column, targetType);
  
  return null;
  }


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

[1/6] cassandra git commit: Fix index target computation for dense composite tables with dropped compact storage

[ifesdjeen]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 5050aa347 -> 0521f8dc5
  refs/heads/cassandra-3.11 95c8aef81 -> adc32ac83
  refs/heads/trunk 6cd400933 -> 8764ef2da


Fix index target computation for dense composite tables with dropped compact 
storage

Patch by Alex Petrov; reviewed by Zhao Yang for CASSANDRA-14104.

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

Branch: refs/heads/cassandra-3.0
Commit: 0521f8dc5d5e05c0530726e9549fa2481726a818
Parents: 5050aa3
Author: Alex Petrov 
Authored: Mon Dec 11 18:56:40 2017 +0100
Committer: Alex Petrov 
Committed: Tue Dec 19 09:55:00 2017 +0100

--
 CHANGES.txt |   1 +
 .../index/internal/CassandraIndex.java  |  33 --
 .../DropCompactStorageThriftTest.java   | 116 +++
 3 files changed, 139 insertions(+), 11 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0521f8dc/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0574893..7746c73 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.16
+ * Fix index target computation for dense composite tables with dropped 
compact storage (CASSANDRA-14104)
  * Improve commit log chain marker updating (CASSANDRA-14108)
  * Extra range tombstone bound creates double rows (CASSANDRA-14008)
  * Fix SStable ordering by max timestamp in SinglePartitionReadCommand 
(CASSANDRA-14010)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0521f8dc/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
--
diff --git a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java 
b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
index 5caeefa..3211fe9 100644
--- a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
+++ b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
@@ -52,6 +52,7 @@ import org.apache.cassandra.db.partitions.PartitionIterator;
 import org.apache.cassandra.db.partitions.PartitionUpdate;
 import org.apache.cassandra.db.rows.*;
 import org.apache.cassandra.dht.LocalPartitioner;
+import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.exceptions.InvalidRequestException;
 import org.apache.cassandra.index.Index;
 import org.apache.cassandra.index.IndexRegistry;
@@ -790,13 +791,20 @@ public abstract class CassandraIndex implements Index
 return getFunctions(indexMetadata, parseTarget(baseCfs.metadata, 
indexMetadata)).newIndexInstance(baseCfs, indexMetadata);
 }
 
-// Public because it's also used to convert index metadata into a 
thrift-compatible format
-public static Pair 
parseTarget(CFMetaData cfm,
-   
IndexMetadata indexDef)
+public static Pair 
parseTarget(CFMetaData cfm, IndexMetadata indexDef)
 {
 String target = indexDef.options.get("target");
 assert target != null : String.format("No target definition found for 
index %s", indexDef.name);
+Pair result = parseTarget(cfm, 
target);
+if (result == null)
+throw new ConfigurationException(String.format("Unable to parse 
targets for index %s (%s)", indexDef.name, target));
+return result;
+}
 
+// Public because it's also used to convert index metadata into a 
thrift-compatible format
+public static Pair 
parseTarget(CFMetaData cfm,
+   String 
target)
+{
 // if the regex matches then the target is in the form "keys(foo)", 
"entries(bar)" etc
 // if not, then it must be a simple column name and implictly its type 
is VALUES
 Matcher matcher = TARGET_REGEX.matcher(target);
@@ -826,15 +834,18 @@ public abstract class CassandraIndex implements Index
 }
 
 // if it's not a CQL table, we can't assume that the column name is 
utf8, so
-// in that case we have to do a linear scan of the cfm's columns to 
get the matching one
-if (cfm.isCQLTable())
-return Pair.create(cfm.getColumnDefinition(new 
ColumnIdentifier(columnName, true)), targetType);
-else
-for (ColumnDefinition column : cfm.allColumns())
-if 

[jira] [Updated] (CASSANDRA-14110) ViewLongTest.testConflictResolution() failed

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-14110:
---
Reviewer: Stefan Podkowinski

> ViewLongTest.testConflictResolution() failed
> 
>
> Key: CASSANDRA-14110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14110
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> The test works fine on my mac, but failed in the 
> [CircleCI|https://circleci.com/gh/cooldoger/cassandra/157]:
> {noformat}
> $ ant long-test -Dtest.name=ViewLongTest
> ...
> [junit] Testcase: 
> testConflictResolution(org.apache.cassandra.cql3.ViewLongTest):   Caused an 
> ERROR
> [junit] [localhost/127.0.0.1:40644] Timed out waiting for server response
> [junit] com.datastax.driver.core.exceptions.OperationTimedOutException: 
> [localhost/127.0.0.1:40644] Timed out waiting for server response
> [junit] at 
> com.datastax.driver.core.exceptions.OperationTimedOutException.copy(OperationTimedOutException.java:44)
> [junit] at 
> com.datastax.driver.core.exceptions.OperationTimedOutException.copy(OperationTimedOutException.java:26)
> [junit] at 
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
> [junit] at 
> com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
> [junit] at 
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:68)
> [junit] at 
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:51)
> [junit] at 
> org.apache.cassandra.cql3.CQLTester.executeNet(CQLTester.java:829)
> [junit] at 
> org.apache.cassandra.cql3.ViewLongTest.testConflictResolution(ViewLongTest.java:138)
> [junit] Caused by: 
> com.datastax.driver.core.exceptions.OperationTimedOutException: 
> [localhost/127.0.0.1:40644] Timed out waiting for server response
> [junit] at 
> com.datastax.driver.core.RequestHandler$SpeculativeExecution.onTimeout(RequestHandler.java:800)
> [junit] at 
> com.datastax.driver.core.Connection$ResponseHandler$1.run(Connection.java:1382)
> [junit] at 
> com.datastax.shaded.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:663)
> [junit] at 
> com.datastax.shaded.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:738)
> [junit] at 
> com.datastax.shaded.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:466)
> [junit] at 
> com.datastax.shaded.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
> [junit] at java.lang.Thread.run(Thread.java:745)
> [junit]
> [junit]
> [junit] Testcase: 
> testConflictResolution(org.apache.cassandra.cql3.ViewLongTest):   Caused an 
> ERROR
> [junit] [localhost/127.0.0.1:40644] Timed out waiting for server response
> [junit] com.datastax.driver.core.exceptions.OperationTimedOutException: 
> [localhost/127.0.0.1:40644] Timed out waiting for server response
> [junit] at 
> com.datastax.driver.core.exceptions.OperationTimedOutException.copy(OperationTimedOutException.java:44)
> [junit] at 
> com.datastax.driver.core.exceptions.OperationTimedOutException.copy(OperationTimedOutException.java:26)
> [junit] at 
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
> [junit] at 
> com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
> [junit] at 
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:68)
> [junit] at 
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:51)
> [junit] at 
> org.apache.cassandra.cql3.CQLTester.executeNet(CQLTester.java:829)
> [junit] at 
> org.apache.cassandra.cql3.ViewLongTest.end(ViewLongTest.java:66)
> [junit] Caused by: 
> com.datastax.driver.core.exceptions.OperationTimedOutException: 
> [localhost/127.0.0.1:40644] Timed out waiting for server response
> [junit] at 
> com.datastax.driver.core.RequestHandler$SpeculativeExecution.onTimeout(RequestHandler.java:800)
> [junit] at 
> com.datastax.driver.core.Connection$ResponseHandler$1.run(Connection.java:1382)
> [junit] at 
> com.datastax.shaded.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:663)
> [junit] at 
> com.datastax.shaded.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:738)
> [junit] at 
> com.datastax.shaded.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:466)
> [junit] at 
> 

[jira] [Commented] (CASSANDRA-14110) ViewLongTest.testConflictResolution() failed

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-14110:


>From my understanding the affected code is supposed to make sure that the 
>batch log has been fully replayed until the test moves on. Ignoring timeouts 
>and retry, instead of failing the test, seems to be the more reasonable 
>behavior here.

Can you create patches for 3.0, 3.11, 4.0 and run them on circleCI?

> ViewLongTest.testConflictResolution() failed
> 
>
> Key: CASSANDRA-14110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14110
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> The test works fine on my mac, but failed in the 
> [CircleCI|https://circleci.com/gh/cooldoger/cassandra/157]:
> {noformat}
> $ ant long-test -Dtest.name=ViewLongTest
> ...
> [junit] Testcase: 
> testConflictResolution(org.apache.cassandra.cql3.ViewLongTest):   Caused an 
> ERROR
> [junit] [localhost/127.0.0.1:40644] Timed out waiting for server response
> [junit] com.datastax.driver.core.exceptions.OperationTimedOutException: 
> [localhost/127.0.0.1:40644] Timed out waiting for server response
> [junit] at 
> com.datastax.driver.core.exceptions.OperationTimedOutException.copy(OperationTimedOutException.java:44)
> [junit] at 
> com.datastax.driver.core.exceptions.OperationTimedOutException.copy(OperationTimedOutException.java:26)
> [junit] at 
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
> [junit] at 
> com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
> [junit] at 
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:68)
> [junit] at 
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:51)
> [junit] at 
> org.apache.cassandra.cql3.CQLTester.executeNet(CQLTester.java:829)
> [junit] at 
> org.apache.cassandra.cql3.ViewLongTest.testConflictResolution(ViewLongTest.java:138)
> [junit] Caused by: 
> com.datastax.driver.core.exceptions.OperationTimedOutException: 
> [localhost/127.0.0.1:40644] Timed out waiting for server response
> [junit] at 
> com.datastax.driver.core.RequestHandler$SpeculativeExecution.onTimeout(RequestHandler.java:800)
> [junit] at 
> com.datastax.driver.core.Connection$ResponseHandler$1.run(Connection.java:1382)
> [junit] at 
> com.datastax.shaded.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:663)
> [junit] at 
> com.datastax.shaded.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:738)
> [junit] at 
> com.datastax.shaded.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:466)
> [junit] at 
> com.datastax.shaded.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
> [junit] at java.lang.Thread.run(Thread.java:745)
> [junit]
> [junit]
> [junit] Testcase: 
> testConflictResolution(org.apache.cassandra.cql3.ViewLongTest):   Caused an 
> ERROR
> [junit] [localhost/127.0.0.1:40644] Timed out waiting for server response
> [junit] com.datastax.driver.core.exceptions.OperationTimedOutException: 
> [localhost/127.0.0.1:40644] Timed out waiting for server response
> [junit] at 
> com.datastax.driver.core.exceptions.OperationTimedOutException.copy(OperationTimedOutException.java:44)
> [junit] at 
> com.datastax.driver.core.exceptions.OperationTimedOutException.copy(OperationTimedOutException.java:26)
> [junit] at 
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
> [junit] at 
> com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
> [junit] at 
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:68)
> [junit] at 
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:51)
> [junit] at 
> org.apache.cassandra.cql3.CQLTester.executeNet(CQLTester.java:829)
> [junit] at 
> org.apache.cassandra.cql3.ViewLongTest.end(ViewLongTest.java:66)
> [junit] Caused by: 
> com.datastax.driver.core.exceptions.OperationTimedOutException: 
> [localhost/127.0.0.1:40644] Timed out waiting for server response
> [junit] at 
> com.datastax.driver.core.RequestHandler$SpeculativeExecution.onTimeout(RequestHandler.java:800)
> [junit] at 
> com.datastax.driver.core.Connection$ResponseHandler$1.run(Connection.java:1382)
> [junit] at 
> 

[jira] [Commented] (CASSANDRA-10112) Refuse to start and print txn log information in case of disk corruption

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10112:
--

I cannot recall any specific reason, so I am guessing this was considered an 
improvement.

> Refuse to start and print txn log information in case of disk corruption
> 
>
> Key: CASSANDRA-10112
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10112
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
>Reporter: Stefania
>Assignee: Stefania
>  Labels: doc-impacting
> Fix For: 3.6
>
>
> Transaction logs were introduced by CASSANDRA-7066 and are read during 
> start-up. In case of file system errors, such as disk corruption, we 
> currently log a panic error and leave the sstable files and transaction logs 
> as they are; this is to avoid rolling back a transaction (i.e. deleting 
> files) by mistake.
> We should instead look at the {{disk_failure_policy}} and refuse to start 
> unless the failure policy is {{ignore}}. 
> We should also consider stashing files that cannot be read during startup, 
> either transaction logs or sstables, by moving them to a dedicated 
> sub-folder. 



--
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-14111) Add long-testsome build target to run specific test

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-14111:
---
   Resolution: Fixed
 Reviewer: Stefan Podkowinski
Fix Version/s: 4.0
   Status: Resolved  (was: Patch Available)

Merged on trunk as 6cd40093330bd6b4e9c02fc98dc69e8ff1444e26
Thanks!

> Add long-testsome build target to run specific test
> ---
>
> Key: CASSANDRA-14111
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14111
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Trivial
> Fix For: 4.0
>
>




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

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

cassandra git commit: Add long-testsome target to run specific long test

[spod]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 7a320260e -> 6cd400933


Add long-testsome target to run specific long test

patch by Jay Zhuang; reviewed by Stefan Podkowinski for CASSANDRA-14111


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

Branch: refs/heads/trunk
Commit: 6cd40093330bd6b4e9c02fc98dc69e8ff1444e26
Parents: 7a32026
Author: Jay Zhuang 
Authored: Tue Dec 12 18:47:18 2017 +
Committer: Stefan Podkowinski 
Committed: Tue Dec 19 10:19:23 2017 +0100

--
 build.xml | 11 +++
 1 file changed, 11 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6cd40093/build.xml
--
diff --git a/build.xml b/build.xml
index 6726083..b14d234 100644
--- a/build.xml
+++ b/build.xml
@@ -1282,6 +1282,17 @@
 
   
 
+  
+  
+
+  
+  
+  
+
+  
+
   
 
 


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

[jira] [Updated] (CASSANDRA-13077) Add helper comments for unittest debug

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13077:
---
   Resolution: Fixed
 Reviewer: Stefan Podkowinski
Fix Version/s: (was: 3.0.x)
   4.0
   Status: Resolved  (was: Patch Available)

Merged on trunk as 7a320260e0c8446f1afcf8f67b13470b60842934 

> Add helper comments for unittest debug
> --
>
> Key: CASSANDRA-13077
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13077
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: 13077-3.0.txt
>
>
> Not an issue. Just add comments for future unittest debug. I find it useful, 
> hope it could be merged: 
> [13077-3.0.patch|https://github.com/cooldoger/cassandra/commit/91c98248a7c3427a22b564fc9e86691e7a923b95]



--
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 helper comments for unittest debugging

[spod]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 8b9b72deb -> 7a320260e


Add helper comments for unittest debugging

patch by Jay Zhuang; reviewed by Stefan Podkowinski for CASSANDRA-13077


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

Branch: refs/heads/trunk
Commit: 7a320260e0c8446f1afcf8f67b13470b60842934
Parents: 8b9b72d
Author: Jay Zhuang 
Authored: Fri Dec 23 13:20:47 2016 -0800
Committer: Stefan Podkowinski 
Committed: Tue Dec 19 10:08:40 2017 +0100

--
 build.xml | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7a320260/build.xml
--
diff --git a/build.xml b/build.xml
index 5dee75d..6726083 100644
--- a/build.xml
+++ b/build.xml
@@ -1145,7 +1145,11 @@
 
 
 
-   
+
+
+
 
   
   


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

[jira] [Commented] (CASSANDRA-14102) Vault support for transparent data encryption

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-14102:


I think the whole life-cycle handling of {{EncryptionContext}} and 
{{CipherFactory}} could need a review along with this patch as well. Each hint 
file and commitlog segment will need to instantiate it's own EncryptionContext 
before it can be decrypted, see {{EncryptionContext.createFromMap}}. This will 
also imply to create a new CipherFactory, including a dedicated caffeine cache 
and expensive reflection based configuration and {{KeyProvider}} construction. 
I'm also not sure that we really keep the KeyProvider contract: _"Further, each 
key will be requested non-concurrently (that is, no stampeding herds for the 
same key), although unique keys may be requested concurrently (unless you mark 
@code getSecretKey synchronized)."_ If we create 100x EncryptionContext 
instances there will be just that much key requests against Vault or any other 
implementation. 

> Vault support for transparent data encryption
> -
>
> Key: CASSANDRA-14102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14102
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>  Labels: encryption
> Fix For: 4.x
>
>
> Transparent data encryption provided by CASSANDRA-9945 can currently be used 
> for commitlog and hints. The default {{KeyProvider}} implementation that we 
> ship allows to use a local keystore for storing and retrieving keys. Thanks 
> to the pluggable handling of the {{KeyStore}} provider and basic Vault 
> related classes introduced in CASSANDRA-13971, a Vault based implementation 
> can be provided as {{KeyProvider}} 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] [Updated] (CASSANDRA-14104) Index target doesn't correctly recognise non-UTF column names after COMPACT STORAGE drop

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-14104:

Attachment: ifesdjeen-14104-3.0-dtest.png
ifesdjeen-14104-3.0-testall.png
ifesdjeen-14104-3.11-dtest.png
ifesdjeen-14104-3.11-testall.png
ifesdjeen-14104-trunk-dtest.png
ifesdjeen-14104-trunk-testall.png

Attaching CI results. 
The failures seem unrelated.

> Index target doesn't correctly recognise non-UTF column names after COMPACT 
> STORAGE drop
> 
>
> Key: CASSANDRA-14104
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14104
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
> Attachments: ifesdjeen-14104-3.0-dtest.png, 
> ifesdjeen-14104-3.0-testall.png, ifesdjeen-14104-3.11-dtest.png, 
> ifesdjeen-14104-3.11-testall.png, ifesdjeen-14104-trunk-dtest.png, 
> ifesdjeen-14104-trunk-testall.png
>
>
> Creating a compact storage table with dynamic composite type, then running 
> {{ALTER TALBE ... DROP COMPACT STORAGE}} and then restarting the node will 
> crash Cassandra node, since the Index Target is fetched using hashmap / 
> strict equality. We need to fall back to linear search when index target 
> can't be found (which should not be happening often).



--
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-10112) Refuse to start and print txn log information in case of disk corruption

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-10112:
-

Does anyone remember why we didn't commit this to 3.0 as well?

> Refuse to start and print txn log information in case of disk corruption
> 
>
> Key: CASSANDRA-10112
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10112
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
>Reporter: Stefania
>Assignee: Stefania
>  Labels: doc-impacting
> Fix For: 3.6
>
>
> Transaction logs were introduced by CASSANDRA-7066 and are read during 
> start-up. In case of file system errors, such as disk corruption, we 
> currently log a panic error and leave the sstable files and transaction logs 
> as they are; this is to avoid rolling back a transaction (i.e. deleting 
> files) by mistake.
> We should instead look at the {{disk_failure_policy}} and refuse to start 
> unless the failure policy is {{ignore}}. 
> We should also consider stashing files that cannot be read during startup, 
> either transaction logs or sstables, by moving them to a dedicated 
> sub-folder. 



--
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-14102) Vault support for transparent data encryption

[Stefan Podkowinski (JIRA)]

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

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

> Vault support for transparent data encryption
> -
>
> Key: CASSANDRA-14102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14102
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>  Labels: encryption
> Fix For: 4.x
>
>
> Transparent data encryption provided by CASSANDRA-9945 can currently be used 
> for commitlog and hints. The default {{KeyProvider}} implementation that we 
> ship allows to use a local keystore for storing and retrieving keys. Thanks 
> to the pluggable handling of the {{KeyStore}} provider and basic Vault 
> related classes introduced in CASSANDRA-13971, a Vault based implementation 
> can be provided as {{KeyProvider}} 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