[jira] [Updated] (CASSANDRA-13441) Schema version changes for each upgraded node in a rolling upgrade, causing migration storms

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13441:
---
Summary: Schema version changes for each upgraded node in a rolling 
upgrade, causing migration storms  (was: Schema version uses built-in digest 
which includes timestamps, causing migration storms)

> Schema version changes for each upgraded node in a rolling upgrade, causing 
> migration storms
> 
>
> Key: CASSANDRA-13441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13441
> Project: Cassandra
>  Issue Type: Bug
>  Components: Schema
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 4.x
>
>
> In versions < 3.0, during a rolling upgrade (say 2.0 -> 2.1), the first node 
> to upgrade to 2.1 would add the new tables, setting the new 2.1 version ID, 
> and subsequently upgraded hosts would settle on that version.
> When a 3.0 node upgrades and writes its own new-in-3.0 system tables, it'll 
> write the same tables that exist in the schema with brand new timestamps. As 
> written, this will cause all nodes in the cluster to change schema (to the 
> version with the newest timestamp). On a sufficiently large cluster with a 
> non-trivial schema, this could cause (literally) millions of migration tasks 
> to needlessly bounce across the cluster.



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

[jira] [Updated] (CASSANDRA-13441) Schema version uses built-in digest which includes timestamps, causing migration storms

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13441:
---
Description: 
In versions < 3.0, during a rolling upgrade (say 2.0 -> 2.1), the first node to 
upgrade to 2.1 would add the new tables, setting the new 2.1 version ID, and 
subsequently upgraded hosts would settle on that version.

When a 3.0 node upgrades and writes its own new-in-3.0 system tables, it'll 
write the same tables that exist in the schema with brand new timestamps. As 
written, this will cause all nodes in the cluster to change schema (to the 
version with the newest timestamp). On a sufficiently large cluster with a 
non-trivial schema, this could cause (literally) millions of migration tasks to 
needlessly bounce across the cluster.



  was:
In versions < 3.0, schema was essentially deterministic - a given schema always 
hashed to the same version, so during a rolling upgrade (say 2.0 -> 2.1), the 
first node to upgrade to 2.1 would add the new tables, setting the new 2.1 
version ID, and subsequently upgraded hosts would settle on that version.

In 3.0, we delegate the digest calculation to the post-8099 data structures, 
which are the same digest calculators used in the read path for digest 
match/mismatch - which means it includes timestamps (and ttls).

Since schema will never use TTL, we don't care about TTL fields. Similarly, 
when a 3.0 node upgrades and writes its own new-in-3.0 system tables, it'll 
write the same tables that exist in the schema with brand new timestamps. As 
written, this will cause all nodes in the cluster to change schema (to the 
version with the newest timestamp), and then change a second time as the 
non-system schema is propagated to the newly upgraded nodes.

On a sufficiently large cluster with a non-trivial schema, this could cause 
(literally) millions of migration tasks to needlessly bounce across the cluster.

Up for discussion: if we fix this in 3.0 (say 3.0.X where X >= 14), then any 
3.0 node below this will always mismatch, and cause ping-ponging described in 
CASSANDRA-11050 . However, if we don't fix it, we create a situation that's 
potentially an outage on rolling upgrade. I'm leaning towards a strong warning 
in NEWS about the right way to upgrade, and fixing it in 4.x, but wouldn't mind 
hearing opinions from [~slebresne] and [~iamaleksey] and [~amorton] since you 
three already talked about this on CASSANDRA-11050 . 


> Schema version uses built-in digest which includes timestamps, causing 
> migration storms
> ---
>
> Key: CASSANDRA-13441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13441
> Project: Cassandra
>  Issue Type: Bug
>  Components: Schema
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 4.x
>
>
> In versions < 3.0, during a rolling upgrade (say 2.0 -> 2.1), the first node 
> to upgrade to 2.1 would add the new tables, setting the new 2.1 version ID, 
> and subsequently upgraded hosts would settle on that version.
> When a 3.0 node upgrades and writes its own new-in-3.0 system tables, it'll 
> write the same tables that exist in the schema with brand new timestamps. As 
> written, this will cause all nodes in the cluster to change schema (to the 
> version with the newest timestamp). On a sufficiently large cluster with a 
> non-trivial schema, this could cause (literally) millions of migration tasks 
> to needlessly bounce across the cluster.



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

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

[mshuler]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/trunk
Commit: be49029c1a7bca1c12ccb6acc6d3caf6e4ce9e3a
Parents: e59c5df 71d4f66
Author: Michael Shuler 
Authored: Fri Apr 14 20:06:36 2017 -0500
Committer: Michael Shuler 
Committed: Fri Apr 14 20:06:36 2017 -0500

--

--

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

[mshuler]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/cassandra-3.11
Commit: be49029c1a7bca1c12ccb6acc6d3caf6e4ce9e3a
Parents: e59c5df 71d4f66
Author: Michael Shuler 
Authored: Fri Apr 14 20:06:36 2017 -0500
Committer: Michael Shuler 
Committed: Fri Apr 14 20:06:36 2017 -0500

--

--

[3/6] cassandra git commit: Add 3.0.14 NEWS and CHANGES

[mshuler]

Add 3.0.14 NEWS and CHANGES


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

Branch: refs/heads/trunk
Commit: 71d4f66d7215bd037d9ebb5e78af79ed649c3f27
Parents: 30b01a0
Author: Michael Shuler 
Authored: Fri Apr 14 20:06:18 2017 -0500
Committer: Michael Shuler 
Committed: Fri Apr 14 20:06:18 2017 -0500

--
 CHANGES.txt | 3 +++
 NEWS.txt| 8 
 2 files changed, 11 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/71d4f66d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index eeb71b9..e46abcd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,6 @@
+3.0.14
+ * 
+
 3.0.13
  * Make reading of range tombstones more reliable (CASSANDRA-12811)
  * Fix startup problems due to schema tables not completely flushed 
(CASSANDRA-12213)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/71d4f66d/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index b6faef4..a92fc5d 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+3.0.14
+==
+
+Upgrading
+-
+   - Nothing specific to this release, but please see previous versions 
upgrading section,
+ especially if you are upgrading from 2.2.
+
 3.0.13
 ==
 

[2/6] cassandra git commit: Add 3.0.14 NEWS and CHANGES

[mshuler]

Add 3.0.14 NEWS and CHANGES


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

Branch: refs/heads/cassandra-3.11
Commit: 71d4f66d7215bd037d9ebb5e78af79ed649c3f27
Parents: 30b01a0
Author: Michael Shuler 
Authored: Fri Apr 14 20:06:18 2017 -0500
Committer: Michael Shuler 
Committed: Fri Apr 14 20:06:18 2017 -0500

--
 CHANGES.txt | 3 +++
 NEWS.txt| 8 
 2 files changed, 11 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/71d4f66d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index eeb71b9..e46abcd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,6 @@
+3.0.14
+ * 
+
 3.0.13
  * Make reading of range tombstones more reliable (CASSANDRA-12811)
  * Fix startup problems due to schema tables not completely flushed 
(CASSANDRA-12213)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/71d4f66d/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index b6faef4..a92fc5d 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+3.0.14
+==
+
+Upgrading
+-
+   - Nothing specific to this release, but please see previous versions 
upgrading section,
+ especially if you are upgrading from 2.2.
+
 3.0.13
 ==
 

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

[mshuler]

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: f3dfb15031c40444023ff1ecfd93bac7c373d057
Parents: 1186502 be49029
Author: Michael Shuler 
Authored: Fri Apr 14 20:06:51 2017 -0500
Committer: Michael Shuler 
Committed: Fri Apr 14 20:06:51 2017 -0500

--

--

[1/6] cassandra git commit: Add 3.0.14 NEWS and CHANGES

[mshuler]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 30b01a02f -> 71d4f66d7
  refs/heads/cassandra-3.11 e59c5dfd2 -> be49029c1
  refs/heads/trunk 11865028a -> f3dfb1503


Add 3.0.14 NEWS and CHANGES


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

Branch: refs/heads/cassandra-3.0
Commit: 71d4f66d7215bd037d9ebb5e78af79ed649c3f27
Parents: 30b01a0
Author: Michael Shuler 
Authored: Fri Apr 14 20:06:18 2017 -0500
Committer: Michael Shuler 
Committed: Fri Apr 14 20:06:18 2017 -0500

--
 CHANGES.txt | 3 +++
 NEWS.txt| 8 
 2 files changed, 11 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/71d4f66d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index eeb71b9..e46abcd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,6 @@
+3.0.14
+ * 
+
 3.0.13
  * Make reading of range tombstones more reliable (CASSANDRA-12811)
  * Fix startup problems due to schema tables not completely flushed 
(CASSANDRA-12213)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/71d4f66d/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index b6faef4..a92fc5d 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+3.0.14
+==
+
+Upgrading
+-
+   - Nothing specific to this release, but please see previous versions 
upgrading section,
+ especially if you are upgrading from 2.2.
+
 3.0.13
 ==
 

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

[mshuler]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/cassandra-3.11
Commit: e59c5dfd29c623363ed2d6408417e027ce3a7472
Parents: 0a438d5 30b01a0
Author: Michael Shuler 
Authored: Fri Apr 14 20:02:58 2017 -0500
Committer: Michael Shuler 
Committed: Fri Apr 14 20:02:58 2017 -0500

--

--

[1/6] cassandra git commit: Increment version to 3.0.14

[mshuler]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 91661ec29 -> 30b01a02f
  refs/heads/cassandra-3.11 0a438d59e -> e59c5dfd2
  refs/heads/trunk 82668ff75 -> 11865028a


Increment version to 3.0.14


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

Branch: refs/heads/cassandra-3.0
Commit: 30b01a02fe3651684f54c1170e5dfee1dd349aef
Parents: 91661ec
Author: Michael Shuler 
Authored: Fri Apr 14 20:02:43 2017 -0500
Committer: Michael Shuler 
Committed: Fri Apr 14 20:02:43 2017 -0500

--
 build.xml| 2 +-
 debian/changelog | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/30b01a02/build.xml
--
diff --git a/build.xml b/build.xml
index e483265..ce12b90 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/30b01a02/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 6067541..34b27c7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (3.0.14) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Fri, 14 Apr 2017 20:01:02 -0500
+
 cassandra (3.0.13) unstable; urgency=medium
 
   * New release

[3/6] cassandra git commit: Increment version to 3.0.14

[mshuler]

Increment version to 3.0.14


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

Branch: refs/heads/trunk
Commit: 30b01a02fe3651684f54c1170e5dfee1dd349aef
Parents: 91661ec
Author: Michael Shuler 
Authored: Fri Apr 14 20:02:43 2017 -0500
Committer: Michael Shuler 
Committed: Fri Apr 14 20:02:43 2017 -0500

--
 build.xml| 2 +-
 debian/changelog | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/30b01a02/build.xml
--
diff --git a/build.xml b/build.xml
index e483265..ce12b90 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/30b01a02/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 6067541..34b27c7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (3.0.14) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Fri, 14 Apr 2017 20:01:02 -0500
+
 cassandra (3.0.13) unstable; urgency=medium
 
   * New release

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

[mshuler]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/trunk
Commit: e59c5dfd29c623363ed2d6408417e027ce3a7472
Parents: 0a438d5 30b01a0
Author: Michael Shuler 
Authored: Fri Apr 14 20:02:58 2017 -0500
Committer: Michael Shuler 
Committed: Fri Apr 14 20:02:58 2017 -0500

--

--

[2/6] cassandra git commit: Increment version to 3.0.14

[mshuler]

Increment version to 3.0.14


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

Branch: refs/heads/cassandra-3.11
Commit: 30b01a02fe3651684f54c1170e5dfee1dd349aef
Parents: 91661ec
Author: Michael Shuler 
Authored: Fri Apr 14 20:02:43 2017 -0500
Committer: Michael Shuler 
Committed: Fri Apr 14 20:02:43 2017 -0500

--
 build.xml| 2 +-
 debian/changelog | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/30b01a02/build.xml
--
diff --git a/build.xml b/build.xml
index e483265..ce12b90 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/30b01a02/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 6067541..34b27c7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (3.0.14) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Fri, 14 Apr 2017 20:01:02 -0500
+
 cassandra (3.0.13) unstable; urgency=medium
 
   * New release

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

[mshuler]

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: 11865028a9b919b26f2bb3c90254363c4db238e7
Parents: 82668ff e59c5df
Author: Michael Shuler 
Authored: Fri Apr 14 20:03:12 2017 -0500
Committer: Michael Shuler 
Committed: Fri Apr 14 20:03:12 2017 -0500

--

--

[jira] [Commented] (CASSANDRA-13433) RPM distribution improvements and known issues

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-13433:


3.0.x example yum configuration with gpgcheck disabled:
{code:title=/etc/yum.repos.d/cassandra.repo}
[cassandra]
name=Apache Cassandra
baseurl=https://www.apache.org/dist/cassandra/redhat/30x/
gpgcheck=0
gpgkey=https://www.apache.org/dist/cassandra/KEYS
{code}

> RPM distribution improvements and known issues
> --
>
> Key: CASSANDRA-13433
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13433
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Stefan Podkowinski
>
> Starting with CASSANDRA-13252, new releases will be provided as both official 
> RPM and Debian packages.  While the Debian packages are already well 
> established with our user base, the RPMs just have been release for the first 
> time and still require some attention. 
> Feel free to discuss RPM related issues in this ticket and open a sub-task to 
> fill a bug report. 
> Please note that native systemd support will be implemented with 
> CASSANDRA-13148 and this is not strictly a RPM specific issue. We still 
> intent to offer non-systemd support based on the already working init scripts 
> that we ship. Therefor the first step is to make use of systemd backward 
> compatibility for SysV/LSB scripts, so we can provide RPMs for both systemd 
> and non-systemd environments.



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

[jira] [Updated] (CASSANDRA-13397) Return value of CountDownLatch.await() not being checked in Repair

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-13397:
---
Fix Version/s: (was: 3.0.13)
   3.0.x

> Return value of CountDownLatch.await() not being checked in Repair
> --
>
> Key: CASSANDRA-13397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13397
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Minor
> Fix For: 3.0.x
>
> Attachments: CASSANDRA-13397-v1.patch
>
>
> While looking into repair code, I realize that we should check return value 
> of CountDownLatch.await(). Most of the places that we don't check the return 
> value, nothing bad would happen due to other protection. However, 
> ActiveRepairService#prepareForRepair should have the check. Code to reproduce:
> {code}
> public static void testLatch() throws InterruptedException {
> CountDownLatch latch = new CountDownLatch(2);
> latch.countDown();
> new Thread(() -> {
> try {
> Thread.sleep(1200);
> } catch (InterruptedException e) {
> System.err.println("interrupted");
> }
> latch.countDown();
> System.out.println("counted down");
> }).start();
> latch.await(1, TimeUnit.SECONDS);
> if (latch.getCount() > 0) {
> System.err.println("failed");
> } else {
> System.out.println("success");
> }
> }
> {code}



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

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

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-13216:
---
Fix Version/s: (was: 3.0.13)
   (was: 3.11.0)
   (was: 4.0)
   4.x
   3.11.x
   3.0.x

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



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

[jira] [Updated] (CASSANDRA-13323) IncomingTcpConnection closed due to one bad message

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-13323:
---
Fix Version/s: (was: 3.0.13)
   3.0.x

> IncomingTcpConnection closed due to one bad message
> ---
>
> Key: CASSANDRA-13323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13323
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Zhou
>Assignee: Simon Zhou
> Fix For: 3.0.x
>
> Attachments: CASSANDRA-13323-v1.patch
>
>
> We got this exception:
> {code}
> WARN  [MessagingService-Incoming-/] 2017-02-14 17:33:33,177 
> IncomingTcpConnection.java:101 - UnknownColumnFamilyException reading from 
> socket; closing
> org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find table for 
> cfId 2a3ab630-df74-11e6-9f81-b56251e1559e. If a table was just created, this 
> is likely due to the schema not being fully propagated.  Please wait for 
> schema agreement on table creation.
> at 
> org.apache.cassandra.config.CFMetaData$Serializer.deserialize(CFMetaData.java:1336)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize30(PartitionUpdate.java:660)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize(PartitionUpdate.java:635)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.service.paxos.Commit$CommitSerializer.deserialize(Commit.java:131)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.service.paxos.Commit$CommitSerializer.deserialize(Commit.java:113)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.net.MessageIn.read(MessageIn.java:98) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:201)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:178)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:92)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> {code}
> Also we saw this log in another host indicating it needs to re-connect:
> {code}
> INFO  [HANDSHAKE-/] 2017-02-21 13:37:50,216 
> OutboundTcpConnection.java:515 - Handshaking version with /
> {code}
> The reason is that the node was receiving hinted data for a dropped table. 
> This may happen with other messages as well. On Cassandra side, 
> IncomingTcpConnection shouldn't close on just one bad message, even though it 
> will be restarted soon later by SocketThread in MessagingService.



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

[jira] [Updated] (CASSANDRA-13276) Regression on CASSANDRA-11416: can't load snapshots of tables with dropped columns

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-13276:
---
Fix Version/s: (was: 3.0.13)
   (was: 3.11.0)
   (was: 4.0)
   4.x
   3.11.x
   3.0.x

> Regression on CASSANDRA-11416: can't load snapshots of tables with dropped 
> columns
> --
>
> Key: CASSANDRA-13276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13276
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Matt Kopit
>Assignee: Andrés de la Peña
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> I'm running Cassandra 3.10 and running into the exact same issue described in 
> CASSANDRA-11416: 
> 1. A table is created with columns 'a' and 'b'
> 2. Data is written to the table
> 3. Drop column 'b'
> 4. Take a snapshot
> 5. Drop the table
> 6. Run the snapshot schema.cql to recreate the table and the run the alter
> 7. Try to restore the snapshot data using sstableloader
> sstableloader yields the error:
> java.lang.RuntimeException: Unknown column b during deserialization



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

[jira] [Commented] (CASSANDRA-10404) Node to Node encryption transitional mode

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-10404:
-

Linked is a first pass at implementing this behavior, based on the current 
(in-flight) CASSANDRA-8457. I'm posting this now to get some feedback on the 
idea/implementation. Hence, I haven't added tests (or dtests) yet. As 
[~spo...@gmail.com] noted, adding in this functionality is rather trivial with 
CASSADNRA-8457 in place. 

The essence of this patch is to add two new configuration props to the 
{{ServerEncryptionOptions}}, {{optional}} and {{enabled}}. They will be 
functional equivalent to what we already have for {{ClientEncryptionOptions}}, 
and thus allow us to do unencrypted and encrypted communication from the same 
listening internode messaging socket. Most of the patch is refactoring of the 
{{EncryptionOptions}} and {{OptionalSslHandler}} classes, and the interesting 
functional bits are in the yaml and MessagingService.

bq. But how would we handle such transition when it comes to used storage_ports?

I'm imagining that for 4.0 we still need both {{storage_port}} and 
{{ssl_storage_port}} in place to support cluster upgrades. Upgraded nodes will 
be smart enough to connect on the {{storage_port}} (which will be intelligent 
to figure out if the connection is TLS or not). Unupgraded nodes can still 
connect on the legacy port (as we'll need to listen on it, as well). At 5.0, 
then, we can retire the {{ssl_storage_port}} and simply have one port and 
config option for internode messaging with TLS.

Also, once this ticket is in place, it will make [~aweisberg]'s patch for 
CASSANDRA-7544 simpler as he won't (hopefully!) need to worry about passing 
around the {{ssl_storge_port}} as all 4.0 nodes who can listen to the new 
CASSANDRA-7544 data being passed around will also be smart enough to connect to 
the {{storage_port}} for TLS behavior. Hence, another reason I'm eager to get 
this in.

> Node to Node encryption transitional mode
> -
>
> Key: CASSANDRA-10404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10404
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Tom Lewis
>Assignee: Jason Brown
>
> Create a transitional mode for encryption that allows encrypted and 
> unencrypted traffic node-to-node during a change over to encryption from 
> unencrypted. This alleviates downtime during the switch.
>  This is similar to CASSANDRA-10559 which is intended for client-to-node



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

[jira] [Resolved] (CASSANDRA-13252) Include RPM packages in releases

[Michael Shuler (JIRA)]

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

Michael Shuler resolved CASSANDRA-13252.

Resolution: Fixed

Closing this out. Parent RPM improvement ticket for tasks from this point: 
CASSANDRA-13433

Thanks for the help, [~spo...@gmail.com]!

> Include RPM packages in releases
> 
>
> Key: CASSANDRA-13252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13252
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Packaging
>Reporter: Michael Shuler
>Assignee: Michael Shuler
> Attachments: rpm_download.diff
>
>
> CASSANDRA-13230 sets up docker builds for deb and rpm packages out of the 
> {{cassandra-builds}} git repo. We should now be able to do builds in CI, at 
> least for build testing of snapshot packages.
> In order to include in releases, we may wish to set up bintray for RPMs in a 
> {{redhat/}} dir, similar to the current {{debian/}} dir redirect from 
> cassandra-dist, or start with direct downloads from cassandra-dist and see 
> how it goes.



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

[jira] [Updated] (CASSANDRA-10404) Node to Node encryption transitional mode

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-10404:

Status: Awaiting Feedback  (was: In Progress)

> Node to Node encryption transitional mode
> -
>
> Key: CASSANDRA-10404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10404
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Tom Lewis
>Assignee: Jason Brown
>
> Create a transitional mode for encryption that allows encrypted and 
> unencrypted traffic node-to-node during a change over to encryption from 
> unencrypted. This alleviates downtime during the switch.
>  This is similar to CASSANDRA-10559 which is intended for client-to-node



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

[jira] [Comment Edited] (CASSANDRA-10404) Node to Node encryption transitional mode

[Jason Brown (JIRA)]

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

Jason Brown edited comment on CASSANDRA-10404 at 4/15/17 12:45 AM:
---

Linked is a first pass at implementing this behavior, based on the current 
(in-flight) CASSANDRA-8457. I'm posting this now to get some feedback on the 
idea/implementation. Hence, I haven't added tests (or dtests) yet. As 
[~spo...@gmail.com] noted, adding in this functionality is rather trivial with 
CASSANDRA-8457 in place. 

The essence of this patch is to add two new configuration props to the 
{{ServerEncryptionOptions}}, {{optional}} and {{enabled}}. They will be 
functional equivalent to what we already have for {{ClientEncryptionOptions}}, 
and thus allow us to do unencrypted and encrypted communication from the same 
listening internode messaging socket. Most of the patch is refactoring of the 
{{EncryptionOptions}} and {{OptionalSslHandler}} classes, and the interesting 
functional bits are in the yaml and MessagingService.

bq. But how would we handle such transition when it comes to used storage_ports?

I'm imagining that for 4.0 we still need both {{storage_port}} and 
{{ssl_storage_port}} in place to support cluster upgrades. Upgraded nodes will 
be smart enough to connect on the {{storage_port}} (which will be intelligent 
to figure out if the connection is TLS or not). Unupgraded nodes can still 
connect on the legacy port (as we'll need to listen on it, as well). At 5.0, 
then, we can retire the {{ssl_storage_port}} and simply have one port and 
config option for internode messaging with TLS.

Also, once this ticket is in place, it will make [~aweisberg]'s patch for 
CASSANDRA-7544 simpler as he won't (hopefully!) need to worry about passing 
around the {{ssl_storge_port}} as all 4.0 nodes who can listen to the new 
CASSANDRA-7544 data being passed around will also be smart enough to connect to 
the {{storage_port}} for TLS behavior. Hence, another reason I'm eager to get 
this in.


was (Author: jasobrown):
Linked is a first pass at implementing this behavior, based on the current 
(in-flight) CASSANDRA-8457. I'm posting this now to get some feedback on the 
idea/implementation. Hence, I haven't added tests (or dtests) yet. As 
[~spo...@gmail.com] noted, adding in this functionality is rather trivial with 
CASSADNRA-8457 in place. 

The essence of this patch is to add two new configuration props to the 
{{ServerEncryptionOptions}}, {{optional}} and {{enabled}}. They will be 
functional equivalent to what we already have for {{ClientEncryptionOptions}}, 
and thus allow us to do unencrypted and encrypted communication from the same 
listening internode messaging socket. Most of the patch is refactoring of the 
{{EncryptionOptions}} and {{OptionalSslHandler}} classes, and the interesting 
functional bits are in the yaml and MessagingService.

bq. But how would we handle such transition when it comes to used storage_ports?

I'm imagining that for 4.0 we still need both {{storage_port}} and 
{{ssl_storage_port}} in place to support cluster upgrades. Upgraded nodes will 
be smart enough to connect on the {{storage_port}} (which will be intelligent 
to figure out if the connection is TLS or not). Unupgraded nodes can still 
connect on the legacy port (as we'll need to listen on it, as well). At 5.0, 
then, we can retire the {{ssl_storage_port}} and simply have one port and 
config option for internode messaging with TLS.

Also, once this ticket is in place, it will make [~aweisberg]'s patch for 
CASSANDRA-7544 simpler as he won't (hopefully!) need to worry about passing 
around the {{ssl_storge_port}} as all 4.0 nodes who can listen to the new 
CASSANDRA-7544 data being passed around will also be smart enough to connect to 
the {{storage_port}} for TLS behavior. Hence, another reason I'm eager to get 
this in.

> Node to Node encryption transitional mode
> -
>
> Key: CASSANDRA-10404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10404
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Tom Lewis
>Assignee: Jason Brown
>
> Create a transitional mode for encryption that allows encrypted and 
> unencrypted traffic node-to-node during a change over to encryption from 
> unencrypted. This alleviates downtime during the switch.
>  This is similar to CASSANDRA-10559 which is intended for client-to-node



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

[jira] [Commented] (CASSANDRA-13252) Include RPM packages in releases

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-13252:


GPG signature on {{repomd.xml}} wasn't sufficient. Unsigned repo config:
{noformat}
[cassandra]
name=Apache Cassandra
baseurl=https://www.apache.org/dist/cassandra/redhat/30x/
gpgcheck=0
gpgkey=https://www.apache.org/dist/cassandra/KEYS
{noformat}

> Include RPM packages in releases
> 
>
> Key: CASSANDRA-13252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13252
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Packaging
>Reporter: Michael Shuler
>Assignee: Michael Shuler
> Attachments: rpm_download.diff
>
>
> CASSANDRA-13230 sets up docker builds for deb and rpm packages out of the 
> {{cassandra-builds}} git repo. We should now be able to do builds in CI, at 
> least for build testing of snapshot packages.
> In order to include in releases, we may wish to set up bintray for RPMs in a 
> {{redhat/}} dir, similar to the current {{debian/}} dir redirect from 
> cassandra-dist, or start with direct downloads from cassandra-dist and see 
> how it goes.



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

[jira] [Commented] (CASSANDRA-13440) Sign RPM artifacts

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-13440:


GPG signature on {{repomd.xml}} must not be sufficient. CentOS7 complained 
{{Package cassandra-3.0.13-1.noarch.rpm is not signed}} with gpgcheck enabled. 
Here's a good non-gpg-check yum config:
{noformat}
[cassandra]
name=Apache Cassandra
baseurl=https://www.apache.org/dist/cassandra/redhat/30x/
gpgcheck=0
gpgkey=https://www.apache.org/dist/cassandra/KEYS
{noformat}

> Sign RPM artifacts
> --
>
> Key: CASSANDRA-13440
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13440
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Packaging
>Reporter: Stefan Podkowinski
>
> RPMs should be gpg signed just as the deb packages. Also add documentation 
> how to verify to download page.



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

[jira] [Updated] (CASSANDRA-13440) Sign RPM artifacts

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-13440:
---
Summary: Sign RPM artifacts  (was: Sign RPM artefacts)

> Sign RPM artifacts
> --
>
> Key: CASSANDRA-13440
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13440
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Packaging
>Reporter: Stefan Podkowinski
>
> RPMs should be gpg signed just as the deb packages. Also add documentation 
> how to verify to download page.



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

[jira] [Commented] (CASSANDRA-13440) Sign RPM artefacts

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-13440:


{noformat}
cd $SVNDIR/cassandra-dist/redhat/30x
createrepo .
gpg --detach-sign --armor repodata/repomd.xml
{noformat}

> Sign RPM artefacts
> --
>
> Key: CASSANDRA-13440
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13440
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Packaging
>Reporter: Stefan Podkowinski
>
> RPMs should be gpg signed just as the deb packages. Also add documentation 
> how to verify to download page.



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

[jira] [Commented] (CASSANDRA-13252) Include RPM packages in releases

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-13252:


Added your download notes, thanks.

I have built the yum repo with {{createrepo}} and I believe the only signature 
needed is on the {{repomd.xml}} file, so I did get that uploaded as well, but 
I'm not completely sure on that.

I think following the same versioned directory scheme as debian {{dist}} is 
prudent to prevent unexpected major version upgrades, so that's what I did for 
this trial run.

http://www.apache.org/dist/cassandra/redhat/

I'll see if I can knock out a yum config with the correct lines, so we can post 
that on the download page.

> Include RPM packages in releases
> 
>
> Key: CASSANDRA-13252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13252
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Packaging
>Reporter: Michael Shuler
>Assignee: Michael Shuler
> Attachments: rpm_download.diff
>
>
> CASSANDRA-13230 sets up docker builds for deb and rpm packages out of the 
> {{cassandra-builds}} git repo. We should now be able to do builds in CI, at 
> least for build testing of snapshot packages.
> In order to include in releases, we may wish to set up bintray for RPMs in a 
> {{redhat/}} dir, similar to the current {{debian/}} dir redirect from 
> cassandra-dist, or start with direct downloads from cassandra-dist and see 
> how it goes.



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

svn commit: r1791429 - in /cassandra/site: publish/download/index.html src/download.md

[mshuler]

Author: mshuler
Date: Fri Apr 14 23:36:03 2017
New Revision: 1791429

URL: http://svn.apache.org/viewvc?rev=1791429=rev
Log:
Add RPM download notes

Modified:
cassandra/site/publish/download/index.html
cassandra/site/src/download.md

Modified: cassandra/site/publish/download/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1791429=1791428=1791429=diff
==
--- cassandra/site/publish/download/index.html (original)
+++ cassandra/site/publish/download/index.html Fri Apr 14 23:36:03 2017
@@ -177,6 +177,32 @@ configuration changes.
   Start-up options (heap size, etc) can be configured in 
/etc/default/cassandra.
 
 
+Installation from RPM packages
+
+Cassandra can currently only be installed manually from downloaded RPM 
packages. We’ll work on making upcoming releases available through 
repositories in the future.
+
+The following versions are currently available for download:
+
+
+  TODO: 3.0.13 (pgp, md5 and sha1)
+
+
+Any instructions have been tested with CentOS 7 and should work for all 
Redhat based distributions. Please see note on end of this section on how to 
report any issues.
+
+Start Cassandra (will not start automatically):
+
+service cassandra start
+
+
+Systemd based distributions may require to run systemctl 
daemon-reload once to make Cassandra available as a systemd service. 
This should happen automatically by running the command above.
+
+Make Cassandra start automatically after reboot:
+
+chkconfig cassandra on
+
+
+Please note that official RPMs for Apache Cassandra only have been 
available recently and are not tested thoroughly on all platforms yet. We 
appreciate your feedback and support and ask you to post details on any issues 
in the https://issues.apache.org/jira/browse/CASSANDRA-13433;>corresponding Jira 
ticket.
+
 Source
 
 Development is done in the Apache Git repository. To check out a copy:

Modified: cassandra/site/src/download.md
URL: 
http://svn.apache.org/viewvc/cassandra/site/src/download.md?rev=1791429=1791428=1791429=diff
==
--- cassandra/site/src/download.md (original)
+++ cassandra/site/src/download.md Fri Apr 14 23:36:03 2017
@@ -80,6 +80,34 @@ sudo apt-get install cassandra
 * The default location of log and data directories is `/var/log/cassandra/` 
and `/var/lib/cassandra`.
 * Start-up options (heap size, etc) can be configured in 
`/etc/default/cassandra`.
 
+### Installation from RPM packages
+
+Cassandra can currently only be installed manually from downloaded RPM 
packages. We'll work on making upcoming releases available through repositories 
in the future.
+
+The following versions are currently available for download:
+
+* TODO: 3.0.13 (pgp, md5 and sha1)
+
+Any instructions have been tested with CentOS 7 and should work for all Redhat 
based distributions. Please see note on end of this section on how to report 
any issues.
+
+Start Cassandra (will not start automatically):
+
+```
+service cassandra start
+```
+
+Systemd based distributions may require to run `systemctl daemon-reload` once 
to make Cassandra available as a systemd service. This should happen 
automatically by running the command above.
+
+Make Cassandra start automatically after reboot:
+
+```
+chkconfig cassandra on
+```
+
+Please note that official RPMs for Apache Cassandra only have been available 
recently and are not tested thoroughly on all platforms yet. We appreciate your 
feedback and support and ask you to post details on any issues in the 
[corresponding Jira 
ticket](https://issues.apache.org/jira/browse/CASSANDRA-13433).
+
+
+
 ### Source
 
 Development is done in the Apache Git repository. To check out a copy:

cassandra git commit: ninja: fixing MetadataSerializerTest

[bdeggleston]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 8a6fc4e2a -> 82668ff75


ninja: fixing MetadataSerializerTest


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

Branch: refs/heads/trunk
Commit: 82668ff7524fd060288d7b57e73003500bd5dd5a
Parents: 8a6fc4e
Author: Blake Eggleston 
Authored: Fri Apr 14 11:33:07 2017 -0700
Committer: Blake Eggleston 
Committed: Fri Apr 14 16:32:14 2017 -0700

--
 .../io/sstable/metadata/MetadataSerializerTest.java  | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/82668ff7/test/unit/org/apache/cassandra/io/sstable/metadata/MetadataSerializerTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/io/sstable/metadata/MetadataSerializerTest.java
 
b/test/unit/org/apache/cassandra/io/sstable/metadata/MetadataSerializerTest.java
index b918dfd..95d2a77 100644
--- 
a/test/unit/org/apache/cassandra/io/sstable/metadata/MetadataSerializerTest.java
+++ 
b/test/unit/org/apache/cassandra/io/sstable/metadata/MetadataSerializerTest.java
@@ -121,9 +121,9 @@ public class MetadataSerializerTest
 }
 
 @Test
-public void testMdReadMc() throws IOException
+public void testNaReadMc() throws IOException
 {
-testOldReadsNew("mc", "md");
+testOldReadsNew("mc", "na");
 }
 
 public void testOldReadsNew(String oldV, String newV) throws IOException
@@ -160,7 +160,7 @@ public class MetadataSerializerTest
 {
 Version mc = BigFormat.instance.getVersion("mc");
 assertFalse(mc.hasPendingRepair());
-Version md = BigFormat.instance.getVersion("md");
-assertTrue(md.hasPendingRepair());
+Version na = BigFormat.instance.getVersion("na");
+assertTrue(na.hasPendingRepair());
 }
 }

[jira] [Commented] (CASSANDRA-13257) Add repair streaming preview

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-13257:
-

ok, comments addressed here: 
https://github.com/bdeggleston/cassandra/tree/13257-squashed-trunk
dtest branch here: https://github.com/bdeggleston/cassandra-dtest/tree/13257

> Add repair streaming preview
> 
>
> Key: CASSANDRA-13257
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13257
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Streaming and Messaging
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> It would be useful to be able to estimate the amount of repair streaming that 
> needs to be done, without actually doing any streaming. Our main motivation 
> for this having something this is validating CASSANDRA-9143 in production, 
> but I’d imagine it could also be a useful tool in troubleshooting.



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

svn commit: r1791427 - in /cassandra/site: publish/download/index.html src/_data/releases.yaml

[mshuler]

Author: mshuler
Date: Fri Apr 14 23:20:57 2017
New Revision: 1791427

URL: http://svn.apache.org/viewvc?rev=1791427=rev
Log:
Update site for 3.0.13 release

Modified:
cassandra/site/publish/download/index.html
cassandra/site/src/_data/releases.yaml

Modified: cassandra/site/publish/download/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1791427=1791426=1791427=diff
==
--- cassandra/site/publish/download/index.html (original)
+++ cassandra/site/publish/download/index.html Fri Apr 14 23:20:57 2017
@@ -110,7 +110,7 @@ released against the most recent bug fix
 The following older Cassandra releases are still supported:
 
 
-  Apache Cassandra 3.0 is supported until 6 months after 4.0 
release (date TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/3.0.12/apache-cassandra-3.0.12-bin.tar.gz;>3.0.12
 (http://www.apache.org/dist/cassandra/3.0.12/apache-cassandra-3.0.12-bin.tar.gz.asc;>pgp,
 http://www.apache.org/dist/cassandra/3.0.12/apache-cassandra-3.0.12-bin.tar.gz.md5;>md5
 and http://www.apache.org/dist/cassandra/3.0.12/apache-cassandra-3.0.12-bin.tar.gz.sha1;>sha1),
 released on 2017-03-10.
+  Apache Cassandra 3.0 is supported until 6 months after 4.0 
release (date TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz;>3.0.13
 (http://www.apache.org/dist/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz.asc;>pgp,
 http://www.apache.org/dist/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz.md5;>md5
 and http://www.apache.org/dist/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz.sha1;>sha1),
 released on 2017-04-14.
   Apache Cassandra 2.2 is supported until 4.0 release (date 
TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/2.2.9/apache-cassandra-2.2.9-bin.tar.gz;>2.2.9
 (http://www.apache.org/dist/cassandra/2.2.9/apache-cassandra-2.2.9-bin.tar.gz.asc;>pgp,
 http://www.apache.org/dist/cassandra/2.2.9/apache-cassandra-2.2.9-bin.tar.gz.md5;>md5
 and http://www.apache.org/dist/cassandra/2.2.9/apache-cassandra-2.2.9-bin.tar.gz.sha1;>sha1),
 released on 2017-02-21.
   Apache Cassandra 2.1 is supported until 4.0 release (date 
TBD) with critical fixes only. The latest release is
 http://www.apache.org/dyn/closer.lua/cassandra/2.1.17/apache-cassandra-2.1.17-bin.tar.gz;>2.1.17
 (http://www.apache.org/dist/cassandra/2.1.17/apache-cassandra-2.1.17-bin.tar.gz.asc;>pgp,
 http://www.apache.org/dist/cassandra/2.1.17/apache-cassandra-2.1.17-bin.tar.gz.md5;>md5
 and http://www.apache.org/dist/cassandra/2.1.17/apache-cassandra-2.1.17-bin.tar.gz.sha1;>sha1),
 released on 2017-02-21.

Modified: cassandra/site/src/_data/releases.yaml
URL: 
http://svn.apache.org/viewvc/cassandra/site/src/_data/releases.yaml?rev=1791427=1791426=1791427=diff
==
--- cassandra/site/src/_data/releases.yaml (original)
+++ cassandra/site/src/_data/releases.yaml Fri Apr 14 23:20:57 2017
@@ -7,8 +7,8 @@ latest:
 #  date: 2016-04-01
 
 "3.0":
-  name: 3.0.12
-  date: 2017-03-10
+  name: 3.0.13
+  date: 2017-04-14
 
 "2.2":
   name: 2.2.9

svn commit: r19157 - /release/cassandra/redhat/30x/repodata/repomd.xml.asc

[mshuler]

Author: mshuler
Date: Fri Apr 14 22:50:54 2017
New Revision: 19157

Log:
Add detached gpg signature on repomd.xml

Added:
release/cassandra/redhat/30x/repodata/repomd.xml.asc

Added: release/cassandra/redhat/30x/repodata/repomd.xml.asc
==
--- release/cassandra/redhat/30x/repodata/repomd.xml.asc (added)
+++ release/cassandra/redhat/30x/repodata/repomd.xml.asc Fri Apr 14 22:50:54 
2017
@@ -0,0 +1,17 @@
+-BEGIN PGP SIGNATURE-
+Version: GnuPG v1
+
+iQIcBAABCAAGBQJY8VIEAAoJEKJ4t4H+SyvaYIsP/0r53M07A6nq5kFERKZ1ijPF
+ULlpBrjhsKbwxvbChiKU4Zy9Br1e6uCjrhLzxYvLC3YaJk7XVHIynIXcSB9k7Vci
+KAkEfFkbrLYiepn07D4e+ZvBUeOKDM/9GNhoL4XoIZHEFJv9JJvsAaQs1Kfhmtd6
+AkKed5xQl6zmNKPrk1j0WkKgYXGT93M47IPxDzA9KK70aqj8+2RtsTew7PLJNBX1
+CBZqmRYJ9eus2ndJrdv+mjdBp9bI430j4aKelwdfxEjx3shL0hNAfbW3UHP8tQHT
+T1pWjsU5FS44+7g1pIziDwGlaIRHr1tw6NFWA+q3KMUofbeSCNbqlR9QzyfOk9vo
+PZjLGgcTif1IEKwl4l+eCRpziKdvBAVzB6EDlqlOnZ/LL/7QbhO5DB1fqaZHP3M/
+LQTT+Pn+BTRZx3v6iDtczmaQF5QrNBgw9xh/GFM4AQHpxpw6fH6LLfH2LK4HdsP+
+CjV2Z6TlAeWoCgiwTKpCiSVSq1X7FdUolyA/KwKl+YhJlc0LBfVqyAIBi/k+hbLz
+lgafYgjg+Jv34pNWzrjsaIw7/LxKWU2+Kv0lEIiXfE/qxVTrd0ReA5oCZ0vyR6+8
+ojeB1uZauqH/Mh5HvdrYLsbAMbca+hS7f+TaoBxHID8BMB0dbgrqmXYeQgrHIjJa
+RrUZWH64B1DSxU5M6mks
+=s+Sj
+-END PGP SIGNATURE-

[jira] [Commented] (CASSANDRA-11471) Add SASL mechanism negotiation to the native protocol

[Ben Bromhead (JIRA)]

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

Ben Bromhead commented on CASSANDRA-11471:
--

So I had a look at the cassandra-test branch for the python driver. Default 
highest supported protocol is v4 
(https://github.com/datastax/python-driver/blob/cassandra-test/cassandra/cluster.py#L358)
 which means it should have hit the new code path (e.g. it received a list of 
SASL mechanisms instead of the JAVA class).

The thing is the the python PasswordAuthenticator code doesn't actually care 
about the first server challenge, it just sends the username and password 
irrespective of what the server says as part of the startup message. In 
connection.py I can't see where the authenticator_class ever gets used (it does 
however get assigned).

Which would go someway to explaining why it worked.

In the meantime I've updated my branch to use optional. 

It might make sense to land support for SASL negotiation in the python driver 
first before committing this, however like any protocol change both C* and the 
driver the tests depend on will need to change simultaneously with tests 
potentially breaking in between? Unless there is a process around this? 

> Add SASL mechanism negotiation to the native protocol
> -
>
> Key: CASSANDRA-11471
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11471
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: CQL
>Reporter: Sam Tunnicliffe
>Assignee: Ben Bromhead
>  Labels: client-impacting
> Fix For: 4.x
>
> Attachments: CASSANDRA-11471
>
>
> Introducing an additional message exchange into the authentication sequence 
> would allow us to support multiple authentication schemes and [negotiation of 
> SASL mechanisms|https://tools.ietf.org/html/rfc4422#section-3.2]. 
> The current {{AUTHENTICATE}} message sent from Client to Server includes the 
> java classname of the configured {{IAuthenticator}}. This could be superceded 
> by a new message which lists the SASL mechanisms supported by the server. The 
> client would then respond with a new message which indicates it's choice of 
> mechanism.  This would allow the server to support multiple mechanisms, for 
> example enabling both {{PLAIN}} for username/password authentication and 
> {{EXTERNAL}} for a mechanism for extracting credentials from SSL 
> certificates\* (see the example in 
> [RFC-4422|https://tools.ietf.org/html/rfc4422#appendix-A]). Furthermore, the 
> server could tailor the list of supported mechanisms on a per-connection 
> basis, e.g. only offering certificate based auth to encrypted clients. 
> The client's response should include the selected mechanism and any initial 
> response data. This is mechanism-specific; the {{PLAIN}} mechanism consists 
> of a single round in which the client sends encoded credentials as the 
> initial response data and the server response indicates either success or 
> failure with no futher challenges required.
> From a protocol perspective, after the mechanism negotiation the exchange 
> would continue as in protocol v4, with one or more rounds of 
> {{AUTH_CHALLENGE}} and {{AUTH_RESPONSE}} messages, terminated by an 
> {{AUTH_SUCCESS}} sent from Server to Client upon successful authentication or 
> an {{ERROR}} on auth failure. 
> XMPP performs mechanism negotiation in this way, 
> [RFC-3920|http://tools.ietf.org/html/rfc3920#section-6] includes a good 
> overview.
> \* Note: this would require some a priori agreement between client and server 
> over the implementation of the {{EXTERNAL}} mechanism.



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

svn commit: r19156 - in /release/cassandra: 2.1.16/ 2.2.8/ 3.0.10/ 3.0.11/ 3.0.13/ 3.9/ debian/dists/30x/ debian/dists/30x/main/binary-amd64/ debian/dists/30x/main/binary-i386/ debian/dists/30x/main/s

[mshuler]

Author: mshuler
Date: Fri Apr 14 22:35:25 2017
New Revision: 19156

Log:
Apache Cassandra 3.0.13 Release

Added:
release/cassandra/3.0.13/
release/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz   (with props)
release/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz.asc
release/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz.asc.md5
release/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz.asc.sha1
release/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz.md5
release/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz.sha1
release/cassandra/3.0.13/apache-cassandra-3.0.13-src.tar.gz   (with props)
release/cassandra/3.0.13/apache-cassandra-3.0.13-src.tar.gz.asc
release/cassandra/3.0.13/apache-cassandra-3.0.13-src.tar.gz.asc.md5
release/cassandra/3.0.13/apache-cassandra-3.0.13-src.tar.gz.asc.sha1
release/cassandra/3.0.13/apache-cassandra-3.0.13-src.tar.gz.md5
release/cassandra/3.0.13/apache-cassandra-3.0.13-src.tar.gz.sha1

release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_3.0.13_all.deb   
(with props)
release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.13.diff.gz   
(with props)
release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.13.dsc
release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.13.orig.tar.gz 
  (with props)

release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.13.orig.tar.gz.asc
release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.13_all.deb   
(with props)
release/cassandra/redhat/
release/cassandra/redhat/30x/
release/cassandra/redhat/30x/cassandra-3.0.13-1.noarch.rpm   (with props)
release/cassandra/redhat/30x/cassandra-3.0.13-1.src.rpm   (with props)
release/cassandra/redhat/30x/cassandra-tools-3.0.13-1.noarch.rpm   (with 
props)
release/cassandra/redhat/30x/repodata/

release/cassandra/redhat/30x/repodata/2225eea38b6001788de05ca5eab93f48bc6a9248a261985520bcd7c87cf6cd7c-filelists.xml.gz
   (with props)

release/cassandra/redhat/30x/repodata/3bcf18c0078056067a0d9a8921e90224d1ec90589a3ea2e2b10f68c2fc7fb046-filelists.sqlite.bz2
   (with props)

release/cassandra/redhat/30x/repodata/863c1a058ccac330aa63bf770005a82232a2411e78357c5c5c95dfe9eb472314-primary.xml.gz
   (with props)

release/cassandra/redhat/30x/repodata/867899412feb8f542ccb8b9191fa291a3d1650393c0845d447f06287f4cdc7fd-other.xml.gz
   (with props)

release/cassandra/redhat/30x/repodata/b54d0f422c031602d2b7d20e0d3c639e6abb0611960c6f346b3cd6ca4e7e276a-other.sqlite.bz2
   (with props)

release/cassandra/redhat/30x/repodata/c31d4195ac4ff0cf6f30bf177ab18712b2dffb092a6498189b4d46c8447c0ab5-primary.sqlite.bz2
   (with props)
release/cassandra/redhat/30x/repodata/repomd.xml
Removed:
release/cassandra/2.1.16/
release/cassandra/2.2.8/
release/cassandra/3.0.10/
release/cassandra/3.0.11/
release/cassandra/3.9/
Modified:
release/cassandra/debian/dists/30x/InRelease
release/cassandra/debian/dists/30x/Release
release/cassandra/debian/dists/30x/Release.gpg
release/cassandra/debian/dists/30x/main/binary-amd64/Packages
release/cassandra/debian/dists/30x/main/binary-amd64/Packages.gz
release/cassandra/debian/dists/30x/main/binary-i386/Packages
release/cassandra/debian/dists/30x/main/binary-i386/Packages.gz
release/cassandra/debian/dists/30x/main/source/Sources.gz

Added: release/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz
==
Binary file - no diff available.

Propchange: release/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz
--
svn:mime-type = application/octet-stream

Added: release/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz.asc
==
--- release/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz.asc (added)
+++ release/cassandra/3.0.13/apache-cassandra-3.0.13-bin.tar.gz.asc Fri Apr 14 
22:35:25 2017
@@ -0,0 +1,17 @@
+-BEGIN PGP SIGNATURE-
+Version: GnuPG v1
+
+iQIcBAABCAAGBQJY7RwPAAoJEKJ4t4H+SyvayasQAI28EtK7/6YVdcejWmF/kPCk
+GGiBVzkl6sz1DGxOGCBi9Zbc4Op/y5H/TE1/xF1ZstwRI0RWVYMuYqgVpk8ddJk9
+1Es7aMD7A0/zT5fBzSo5VapfwjuxYUqXAgbEqpiNW2xYYrLJI2mcWb6XeqHiGs1/
+LX062FPAVbQnK0ZB9IHDXMFTlhwSsf8Ol7MC7O7+TnmXnszFgv0yFELmQCTaR6WP
+lqBApimtABNT77NECeh+JAtlAb0ME7ZpCntOtxS1v2PxOXI/u548+KAzz1vR2C5s
+c+cGH1J2AowRA4QwWEDPW3w0PXvz6rt82zhKtJXlqDjqu86HSDNAx0slpfAeDZx1
+5CCn1h80EpHFuk4TVgyPLI/oOgGVjeDX8r8DBdtXujwEDhDEg2FkiofMe/tMNH2l
+TDNzMR1xkl3o28obfG5Fdrp6/q8oJyakOrrn9aUrjYrBTJs/G1mQQ23hDN4GVTo/
+Jk14kP53g3OA5Gz6e6A2k7EFCa7JJ25RWrPFjEM2EzHcVqW+8SB4wOOxqUhaWN34
+uGgaPGqwg6lXxDqHCjLIQUQK5W8PwApt377MgptKE5kga2HZA1b3gIWGOI7WwR9G
+d3rWx42gDWwfc7npjZfkUWigy1GkuC+qT65OOF6WFYADQm+waR5FImCBoK+zypp2
+c2x2pdNsYPCnuJIR4sDl
+=WvNT
+-END PGP SIGNATURE-

Added: 

[cassandra] Git Push Summary

[mshuler]

Repository: cassandra
Updated Tags:  refs/tags/3.0.13-tentative [deleted] 91661ec29

[cassandra] Git Push Summary

[mshuler]

Repository: cassandra
Updated Tags:  refs/tags/cassandra-3.0.13 [created] 2822c6c32

[jira] [Created] (CASSANDRA-13451) add gossip documentation

[Jon Haddad (JIRA)]

Jon Haddad created CASSANDRA-13451:
--

 Summary: add gossip documentation
 Key: CASSANDRA-13451
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13451
 Project: Cassandra
  Issue Type: Test
  Components: Documentation and Website
Reporter: Jon Haddad


There's a decent amount of valid info here: 
https://wiki.apache.org/cassandra/ArchitectureGossip and we have basically 
nothing in the official docs.



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

[jira] [Updated] (CASSANDRA-13441) Schema version uses built-in digest which includes timestamps, causing migration storms

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13441:
---
Reviewer: Aleksey Yeschenko

> Schema version uses built-in digest which includes timestamps, causing 
> migration storms
> ---
>
> Key: CASSANDRA-13441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13441
> Project: Cassandra
>  Issue Type: Bug
>  Components: Schema
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 4.x
>
>
> In versions < 3.0, schema was essentially deterministic - a given schema 
> always hashed to the same version, so during a rolling upgrade (say 2.0 -> 
> 2.1), the first node to upgrade to 2.1 would add the new tables, setting the 
> new 2.1 version ID, and subsequently upgraded hosts would settle on that 
> version.
> In 3.0, we delegate the digest calculation to the post-8099 data structures, 
> which are the same digest calculators used in the read path for digest 
> match/mismatch - which means it includes timestamps (and ttls).
> Since schema will never use TTL, we don't care about TTL fields. Similarly, 
> when a 3.0 node upgrades and writes its own new-in-3.0 system tables, it'll 
> write the same tables that exist in the schema with brand new timestamps. As 
> written, this will cause all nodes in the cluster to change schema (to the 
> version with the newest timestamp), and then change a second time as the 
> non-system schema is propagated to the newly upgraded nodes.
> On a sufficiently large cluster with a non-trivial schema, this could cause 
> (literally) millions of migration tasks to needlessly bounce across the 
> cluster.
> Up for discussion: if we fix this in 3.0 (say 3.0.X where X >= 14), then any 
> 3.0 node below this will always mismatch, and cause ping-ponging described in 
> CASSANDRA-11050 . However, if we don't fix it, we create a situation that's 
> potentially an outage on rolling upgrade. I'm leaning towards a strong 
> warning in NEWS about the right way to upgrade, and fixing it in 4.x, but 
> wouldn't mind hearing opinions from [~slebresne] and [~iamaleksey] and 
> [~amorton] since you three already talked about this on CASSANDRA-11050 . 



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

[jira] [Commented] (CASSANDRA-13421) WriteResponseHandlerTest is sensitive to test execution order

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13421:


lgtm, +1


> WriteResponseHandlerTest is sensitive to test execution order
> -
>
> Key: CASSANDRA-13421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13421
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
> Fix For: 4.0
>
>
> One of the tests checks statistics that aren't reset between tests. If the 
> test doesn't run first then the expected values are incorrect.



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

[jira] [Updated] (CASSANDRA-13441) Schema version uses built-in digest which includes timestamps, causing migration storms

[Jeff Jirsa (JIRA)]

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

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

> Schema version uses built-in digest which includes timestamps, causing 
> migration storms
> ---
>
> Key: CASSANDRA-13441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13441
> Project: Cassandra
>  Issue Type: Bug
>  Components: Schema
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 4.x
>
>
> In versions < 3.0, schema was essentially deterministic - a given schema 
> always hashed to the same version, so during a rolling upgrade (say 2.0 -> 
> 2.1), the first node to upgrade to 2.1 would add the new tables, setting the 
> new 2.1 version ID, and subsequently upgraded hosts would settle on that 
> version.
> In 3.0, we delegate the digest calculation to the post-8099 data structures, 
> which are the same digest calculators used in the read path for digest 
> match/mismatch - which means it includes timestamps (and ttls).
> Since schema will never use TTL, we don't care about TTL fields. Similarly, 
> when a 3.0 node upgrades and writes its own new-in-3.0 system tables, it'll 
> write the same tables that exist in the schema with brand new timestamps. As 
> written, this will cause all nodes in the cluster to change schema (to the 
> version with the newest timestamp), and then change a second time as the 
> non-system schema is propagated to the newly upgraded nodes.
> On a sufficiently large cluster with a non-trivial schema, this could cause 
> (literally) millions of migration tasks to needlessly bounce across the 
> cluster.
> Up for discussion: if we fix this in 3.0 (say 3.0.X where X >= 14), then any 
> 3.0 node below this will always mismatch, and cause ping-ponging described in 
> CASSANDRA-11050 . However, if we don't fix it, we create a situation that's 
> potentially an outage on rolling upgrade. I'm leaning towards a strong 
> warning in NEWS about the right way to upgrade, and fixing it in 4.x, but 
> wouldn't mind hearing opinions from [~slebresne] and [~iamaleksey] and 
> [~amorton] since you three already talked about this on CASSANDRA-11050 . 



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

[jira] [Commented] (CASSANDRA-13441) Schema version uses built-in digest which includes timestamps, causing migration storms

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13441:


Patch for trunk at: https://github.com/jeffjirsa/cassandra/tree/cassandra-13441
CircleCI running unit tests: 
https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-13441
Dtest will run from here: 
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/13/
 (may be quite some time until dtests run, maybe available by Monday)



> Schema version uses built-in digest which includes timestamps, causing 
> migration storms
> ---
>
> Key: CASSANDRA-13441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13441
> Project: Cassandra
>  Issue Type: Bug
>  Components: Schema
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 4.x
>
>
> In versions < 3.0, schema was essentially deterministic - a given schema 
> always hashed to the same version, so during a rolling upgrade (say 2.0 -> 
> 2.1), the first node to upgrade to 2.1 would add the new tables, setting the 
> new 2.1 version ID, and subsequently upgraded hosts would settle on that 
> version.
> In 3.0, we delegate the digest calculation to the post-8099 data structures, 
> which are the same digest calculators used in the read path for digest 
> match/mismatch - which means it includes timestamps (and ttls).
> Since schema will never use TTL, we don't care about TTL fields. Similarly, 
> when a 3.0 node upgrades and writes its own new-in-3.0 system tables, it'll 
> write the same tables that exist in the schema with brand new timestamps. As 
> written, this will cause all nodes in the cluster to change schema (to the 
> version with the newest timestamp), and then change a second time as the 
> non-system schema is propagated to the newly upgraded nodes.
> On a sufficiently large cluster with a non-trivial schema, this could cause 
> (literally) millions of migration tasks to needlessly bounce across the 
> cluster.
> Up for discussion: if we fix this in 3.0 (say 3.0.X where X >= 14), then any 
> 3.0 node below this will always mismatch, and cause ping-ponging described in 
> CASSANDRA-11050 . However, if we don't fix it, we create a situation that's 
> potentially an outage on rolling upgrade. I'm leaning towards a strong 
> warning in NEWS about the right way to upgrade, and fixing it in 4.x, but 
> wouldn't mind hearing opinions from [~slebresne] and [~iamaleksey] and 
> [~amorton] since you three already talked about this on CASSANDRA-11050 . 



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

[jira] [Updated] (CASSANDRA-13336) Upgrade the snappy-java version to 1.1.2.x

[Jeff Jirsa (JIRA)]

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

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

> Upgrade the snappy-java version to 1.1.2.x
> --
>
> Key: CASSANDRA-13336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13336
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: yuqi
>Assignee: Jeff Jirsa
> Fix For: 4.x
>
>
>  Snappy-java added support for AArch64 since version 
> 1.1.2.x.(https://github.com/xerial/snappy-java/pull/135).



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

[jira] [Updated] (CASSANDRA-13336) Upgrade the snappy-java version to 1.1.2.x

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13336:
---
Status: Patch Available  (was: In Progress)

> Upgrade the snappy-java version to 1.1.2.x
> --
>
> Key: CASSANDRA-13336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13336
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: yuqi
>Assignee: Jeff Jirsa
> Fix For: 4.x
>
>
>  Snappy-java added support for AArch64 since version 
> 1.1.2.x.(https://github.com/xerial/snappy-java/pull/135).



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

[jira] [Resolved] (CASSANDRA-12661) Make gc_log and gc_warn settable at runtime

[Blake Eggleston (JIRA)]

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

Blake Eggleston resolved CASSANDRA-12661.
-
Resolution: Fixed

> Make gc_log and gc_warn settable at runtime
> ---
>
> Key: CASSANDRA-12661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12661
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
> Attachments: Screen Shot 2017-04-12 at 11.38.06 AM.png
>
>
> Changes:
> * Move gc_log_threshold_in_ms and gc_warn_threshold_in_ms close together in 
> the config
> * rename variables to match properties
> * add unit tests to ensure hybration
> * add unit tests to ensure variables are set propertly
> * minor perf (do not consturct string from buffer f not logging)



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

[jira] [Commented] (CASSANDRA-12661) Make gc_log and gc_warn settable at runtime

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-12661:
-

Committed test and misc style fixes as 
{{8a6fc4e2ac8012ae2d3e4abf6c6502cbeda5159c}}.

> Make gc_log and gc_warn settable at runtime
> ---
>
> Key: CASSANDRA-12661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12661
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
> Attachments: Screen Shot 2017-04-12 at 11.38.06 AM.png
>
>
> Changes:
> * Move gc_log_threshold_in_ms and gc_warn_threshold_in_ms close together in 
> the config
> * rename variables to match properties
> * add unit tests to ensure hybration
> * add unit tests to ensure variables are set propertly
> * minor perf (do not consturct string from buffer f not logging)



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

cassandra git commit: Fixing failing test and a few style problems introduced in 12661

[bdeggleston]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 02ded0194 -> 8a6fc4e2a


Fixing failing test and a few style problems introduced in 12661

Patch by Ed Capriolo; Reviewed by Blake Eggleston for CASSANDRA-12661


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

Branch: refs/heads/trunk
Commit: 8a6fc4e2ac8012ae2d3e4abf6c6502cbeda5159c
Parents: 02ded01
Author: Edward 
Authored: Wed Apr 12 12:11:00 2017 -0400
Committer: Blake Eggleston 
Committed: Fri Apr 14 09:00:08 2017 -0700

--
 .../apache/cassandra/service/GCInspector.java   | 13 +++---
 .../cassandra/service/GCInspectorTest.java  | 27 +++-
 2 files changed, 30 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8a6fc4e2/src/java/org/apache/cassandra/service/GCInspector.java
--
diff --git a/src/java/org/apache/cassandra/service/GCInspector.java 
b/src/java/org/apache/cassandra/service/GCInspector.java
index b016249..657d3ad 100644
--- a/src/java/org/apache/cassandra/service/GCInspector.java
+++ b/src/java/org/apache/cassandra/service/GCInspector.java
@@ -53,8 +53,8 @@ public class GCInspector implements NotificationListener, 
GCInspectorMXBean
 {
 public static final String MBEAN_NAME = 
"org.apache.cassandra.service:type=GCInspector";
 private static final Logger logger = 
LoggerFactory.getLogger(GCInspector.class);
-private volatile static long gcLogThreshholdInMs = 
DatabaseDescriptor.getGCLogThreshold();
-private volatile static long gcWarnThreasholdInMs = 
DatabaseDescriptor.getGCWarnThreshold();
+private volatile long gcLogThreshholdInMs = 
DatabaseDescriptor.getGCLogThreshold();
+private volatile long gcWarnThreasholdInMs = 
DatabaseDescriptor.getGCWarnThreshold();
 
 /*
  * The field from java.nio.Bits that tracks the total number of allocated
@@ -335,24 +335,21 @@ public class GCInspector implements NotificationListener, 
GCInspectorMXBean
 }
 }
 
-@Override
 public void setGcWarnThresholdInMs(long threshold)
 {
 if (threshold < 0)
-throw new IllegalArgumentException("Threashold must be greater 
than 0");
+throw new IllegalArgumentException("Threshold must be greater than 
or equal to 0");
 if (threshold != 0 && threshold <= gcLogThreshholdInMs)
-throw new IllegalArgumentException("Threashold must be greater 
than gcLogTreasholdInMs which is currently " 
+throw new IllegalArgumentException("Threshold must be greater than 
gcLogTreasholdInMs which is currently " 
 + gcLogThreshholdInMs);
 gcWarnThreasholdInMs = threshold;
 }
 
-@Override
 public long getGcWarnThresholdInMs()
 {
 return gcWarnThreasholdInMs;
 }
 
-@Override
 public void setGcLogThresholdInMs(long threshold)
 {
 if (threshold <= 0)
@@ -363,13 +360,11 @@ public class GCInspector implements NotificationListener, 
GCInspectorMXBean
 gcLogThreshholdInMs = threshold;
 }
 
-@Override
 public long getGcLogThresholdInMs()
 {
 return gcLogThreshholdInMs;
 }
 
-@Override
 public long getStatusThresholdInMs()
 {
 return gcWarnThreasholdInMs != 0 ? gcWarnThreasholdInMs : 
gcLogThreshholdInMs;

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8a6fc4e2/test/unit/org/apache/cassandra/service/GCInspectorTest.java
--
diff --git a/test/unit/org/apache/cassandra/service/GCInspectorTest.java 
b/test/unit/org/apache/cassandra/service/GCInspectorTest.java
index 872c736..0c5ddef 100644
--- a/test/unit/org/apache/cassandra/service/GCInspectorTest.java
+++ b/test/unit/org/apache/cassandra/service/GCInspectorTest.java
@@ -1,3 +1,20 @@
+/*
+ * 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 

[jira] [Commented] (CASSANDRA-10968) When taking snapshot, manifest.json contains incorrect or no files when column family has secondary indexes

[Aleksandr Sorokoumov (JIRA)]

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

Aleksandr Sorokoumov commented on CASSANDRA-10968:
--

Thanks for the question! It is indeed applicable to 3.x, here is the patch: 
https://github.com/Ge/cassandra/tree/10968-3.11

> When taking snapshot, manifest.json contains incorrect or no files when 
> column family has secondary indexes
> ---
>
> Key: CASSANDRA-10968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10968
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Fred A
>Assignee: Aleksandr Sorokoumov
>  Labels: lhf
> Fix For: 2.1.12, 2.2.4, 3.11.0
>
>
> xNoticed indeterminate behaviour when taking snapshot on column families that 
> has secondary indexes setup. The created manifest.json created when doing 
> snapshot, sometimes contains no file names at all and sometimes some file 
> names. 
> I don't know if this post is related but that was the only thing I could find:
> http://www.mail-archive.com/user%40cassandra.apache.org/msg42019.html



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

[jira] [Updated] (CASSANDRA-10968) When taking snapshot, manifest.json contains incorrect or no files when column family has secondary indexes

[Aleksandr Sorokoumov (JIRA)]

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

Aleksandr Sorokoumov updated CASSANDRA-10968:
-
Fix Version/s: 2.2.4
   3.11.0

> When taking snapshot, manifest.json contains incorrect or no files when 
> column family has secondary indexes
> ---
>
> Key: CASSANDRA-10968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10968
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Fred A
>Assignee: Aleksandr Sorokoumov
>  Labels: lhf
> Fix For: 2.1.12, 2.2.4, 3.11.0
>
>
> xNoticed indeterminate behaviour when taking snapshot on column families that 
> has secondary indexes setup. The created manifest.json created when doing 
> snapshot, sometimes contains no file names at all and sometimes some file 
> names. 
> I don't know if this post is related but that was the only thing I could find:
> http://www.mail-archive.com/user%40cassandra.apache.org/msg42019.html



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

[jira] [Updated] (CASSANDRA-10968) When taking snapshot, manifest.json contains incorrect or no files when column family has secondary indexes

[Aleksandr Sorokoumov (JIRA)]

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

Aleksandr Sorokoumov updated CASSANDRA-10968:
-
Reproduced In: 2.2.4, 2.1.12, 3.11.0  (was: 2.1.12, 2.2.4)

> When taking snapshot, manifest.json contains incorrect or no files when 
> column family has secondary indexes
> ---
>
> Key: CASSANDRA-10968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10968
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Fred A
>Assignee: Aleksandr Sorokoumov
>  Labels: lhf
> Fix For: 2.1.12, 2.2.4, 3.11.0
>
>
> xNoticed indeterminate behaviour when taking snapshot on column families that 
> has secondary indexes setup. The created manifest.json created when doing 
> snapshot, sometimes contains no file names at all and sometimes some file 
> names. 
> I don't know if this post is related but that was the only thing I could find:
> http://www.mail-archive.com/user%40cassandra.apache.org/msg42019.html



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

[jira] [Commented] (CASSANDRA-13336) Upgrade the snappy-java version to 1.1.2.x

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13336:
-

A belated +1 for all, please go ahead commit, [~jjirsa]

> Upgrade the snappy-java version to 1.1.2.x
> --
>
> Key: CASSANDRA-13336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13336
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: yuqi
>Assignee: Jeff Jirsa
> Fix For: 4.x
>
>
>  Snappy-java added support for AArch64 since version 
> 1.1.2.x.(https://github.com/xerial/snappy-java/pull/135).



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

[jira] [Commented] (CASSANDRA-13450) repair thread stuck

[Roland Otta (JIRA)]

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

Roland Otta commented on CASSANDRA-13450:
-

the last message in the debug log regarding repairs is from yesterday and there 
was an exception

{noformat}
ERROR [ValidationExecutor:733] 2017-04-13 07:42:52,122 Validator.java:261 - 
Failed creating a merkle tree for [repair #f790a3b0-200b-11e7-832d-63f3cc1716ba 
on bds/adcounter_total, [(6083618763864780186,609059675
8865971039], (5488178912202442861,5490938324381352290]]], /192.168.0.26 (see 
log for details)
ERROR [ValidationExecutor:733] 2017-04-13 07:42:52,123 CassandraDaemon.java:217 
- Exception in thread Thread[ValidationExecutor:733,1,main]
java.lang.NullPointerException: null
at 
org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.getActiveSSTables(ActiveRepairService.java:495)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.access$300(ActiveRepairService.java:451)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.service.ActiveRepairService.currentlyRepairing(ActiveRepairService.java:338)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.compaction.CompactionManager.getSSTablesToValidate(CompactionManager.java:1320)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:1215)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.compaction.CompactionManager.access$700(CompactionManager.java:81)
 ~[apache-cassandra-3.7.jar:3.7]
at 
org.apache.cassandra.db.compaction.CompactionManager$11.call(CompactionManager.java:844)
 ~[apache-cassandra-3.7.jar:3.7]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_77]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_77]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_77]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_77]
{noformat}

> repair thread stuck
> ---
>
> Key: CASSANDRA-13450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13450
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.7
>Reporter: Roland Otta
>
> we sometimes have stuck repair threads in our production system
> this is the corresponding stack trace
> {noformat}
> Name: Repair#202:3
> State: WAITING on 
> com.google.common.util.concurrent.AbstractFuture$Sync@56d7b0ab
> Total blocked: 0  Total waited: 1
> Stack trace: 
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:285)
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:160)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Created] (CASSANDRA-13450) repair thread stuck

[Roland Otta (JIRA)]

Roland Otta created CASSANDRA-13450:
---

 Summary: repair thread stuck
 Key: CASSANDRA-13450
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13450
 Project: Cassandra
  Issue Type: Bug
 Environment: cassandra 3.7
Reporter: Roland Otta


we sometimes have stuck repair threads in our production system

this is the corresponding stack trace

{noformat}
Name: Repair#202:3
State: WAITING on com.google.common.util.concurrent.AbstractFuture$Sync@56d7b0ab
Total blocked: 0  Total waited: 1

Stack trace: 
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:285)
com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)
com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)
org.apache.cassandra.repair.RepairJob.run(RepairJob.java:160)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
{noformat}



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

[jira] [Commented] (CASSANDRA-13307) The specification of protocol version in cqlsh means the python driver doesn't automatically downgrade protocol version.

[mck (JIRA)]

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

mck commented on CASSANDRA-13307:
-

{quote}Hey mck Did you still want me to take a look? {quote}
No [~mbyrd], flakiness on that particular build configuration on the asf 
jenkins is to blame.

I will push the commit as soon as trunk it green again.

> The specification of protocol version in cqlsh means the python driver 
> doesn't automatically downgrade protocol version.
> 
>
> Key: CASSANDRA-13307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13307
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Matt Byrd
>Assignee: Matt Byrd
>Priority: Minor
>  Labels: doc-impacting
> Fix For: 3.11.x
>
>
> Hi,
> Looks like we've regressed on the issue described in:
> https://issues.apache.org/jira/browse/CASSANDRA-9467
> In that we're no longer able to connect from newer cqlsh versions
> (e.g trunk) to older versions of Cassandra with a lower version of the 
> protocol (e.g 2.1 with protocol version 3)
> The problem seems to be that we're relying on the ability for the client to 
> automatically downgrade protocol version implemented in Cassandra here:
> https://issues.apache.org/jira/browse/CASSANDRA-12838
> and utilised in the python client here:
> https://datastax-oss.atlassian.net/browse/PYTHON-240
> The problem however comes when we implemented:
> https://datastax-oss.atlassian.net/browse/PYTHON-537
> "Don't downgrade protocol version if explicitly set" 
> (included when we bumped from 3.5.0 to 3.7.0 of the python driver as part of 
> fixing: https://issues.apache.org/jira/browse/CASSANDRA-11534)
> Since we do explicitly specify the protocol version in the bin/cqlsh.py.
> I've got a patch which just adds an option to explicitly specify the protocol 
> version (for those who want to do that) and then otherwise defaults to not 
> setting the protocol version, i.e using the protocol version from the client 
> which we ship, which should by default be the same protocol as the server.
> Then it should downgrade gracefully as was intended. 
> Let me know if that seems reasonable.
> Thanks,
> Matt



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