[jira] [Commented] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551455#comment-16551455
]
Sumanth Pasupuleti commented on CASSANDRA-14557:
Thanks for reviewing [~jolynch].
* Updated the patch with feedback incorporated
* ccm runs are good
* Added a mention about this ticket to
[CASSANDRA-13701|https://issues.apache.org/jira/browse/CASSANDRA-13701]
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.0
>
> Attachments: 14557-trunk.txt
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumanth Pasupuleti updated CASSANDRA-14557:
---
Attachment: 14557-trunk.txt
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.0
>
> Attachments: 14557-trunk.txt
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551192#comment-16551192
]
Sumanth Pasupuleti edited comment on CASSANDRA-14557 at 7/21/18 12:04 AM:
--
||trunk||
| patch [^14557-trunk.txt] |
|[github|https://github.com/sumanth-pasupuleti/cassandra/tree/CASSANDRA-14557]|
|[unit
tests|https://circleci.com/gh/sumanth-pasupuleti/cassandra/tree/CASSANDRA-14557]|
was (Author: sumanth.pasupuleti):
||trunk||
| patch [^14557-trunk.txt] |
|[github|https://github.com/sumanth-pasupuleti/cassandra/tree/CASSANDRA-14557]|
|[unit
tests|https://circleci.com/gh/sumanth-pasupuleti/cassandra/tree/CASSANDRA-14557]|
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.0
>
> Attachments: 14557-trunk.txt
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumanth Pasupuleti updated CASSANDRA-14557:
---
Attachment: (was: 14557-trunk.txt)
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.0
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14576) Improve logging in MessageInHandler's constructor
[
https://issues.apache.org/jira/browse/CASSANDRA-14576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Brown updated CASSANDRA-14576:
Resolution: Fixed
Status: Resolved (was: Patch Available)
committed as sha {{9abeff38c4bdcd6e640642c38b5f253f0955e6b0}}.
> Improve logging in MessageInHandler's constructor
> -
>
> Key: CASSANDRA-14576
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14576
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Trivial
> Fix For: 4.0
>
>
> There's a minor logging bug in when when complaining about unacceptable
> messaging version in MessageInHandler's constructor. The passed in version
> does not get logged (even though it should).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
cassandra git commit: Improve logging in MessageInHandler's constructor
Repository: cassandra
Updated Branches:
refs/heads/trunk c4263d26b -> 9abeff38c
Improve logging in MessageInHandler's constructor
patch by jasobrown; reviewed by Dinesh Joshi for CASSANDRA-14576
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9abeff38
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9abeff38
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9abeff38
Branch: refs/heads/trunk
Commit: 9abeff38c4bdcd6e640642c38b5f253f0955e6b0
Parents: c4263d2
Author: Jason Brown
Authored: Fri Jul 20 04:50:43 2018 -0700
Committer: Jason Brown
Committed: Fri Jul 20 16:08:53 2018 -0700
--
CHANGES.txt | 1 +
.../apache/cassandra/net/async/MessageInHandler.java | 5 ++---
.../cassandra/net/async/MessageInHandlerPre40.java| 5 ++---
.../cassandra/net/async/MessageInHandlerTest.java | 14 +++---
4 files changed, 16 insertions(+), 9 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9abeff38/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4b53c03..faf37ea 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0
+ * Improve logging in MessageInHandler's constructor (CASSANDRA-14576)
* Set broadcast address in internode messaging handshake (CASSANDRA-14579)
* Wait for schema agreement prior to building MVs (CASSANDRA-14571)
* Make all DDL statements idempotent and not dependent on global state
(CASSANDRA-13426)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9abeff38/src/java/org/apache/cassandra/net/async/MessageInHandler.java
--
diff --git a/src/java/org/apache/cassandra/net/async/MessageInHandler.java
b/src/java/org/apache/cassandra/net/async/MessageInHandler.java
index c85d860..eb22e91 100644
--- a/src/java/org/apache/cassandra/net/async/MessageInHandler.java
+++ b/src/java/org/apache/cassandra/net/async/MessageInHandler.java
@@ -65,9 +65,8 @@ public class MessageInHandler extends BaseMessageInHandler
{
super(peer, messagingVersion, messageConsumer);
-if (messagingVersion < MessagingService.VERSION_40)
-throw new IllegalArgumentException(String.format("wrong messaging
version for this handler", messagingVersion));
-
+assert messagingVersion >= MessagingService.VERSION_40 :
String.format("wrong messaging version for this handler: got %d, but expect %d
or higher",
+
messagingVersion, MessagingService.VERSION_40);
state = State.READ_FIRST_CHUNK;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9abeff38/src/java/org/apache/cassandra/net/async/MessageInHandlerPre40.java
--
diff --git a/src/java/org/apache/cassandra/net/async/MessageInHandlerPre40.java
b/src/java/org/apache/cassandra/net/async/MessageInHandlerPre40.java
index 132ec11..fb19b43 100644
--- a/src/java/org/apache/cassandra/net/async/MessageInHandlerPre40.java
+++ b/src/java/org/apache/cassandra/net/async/MessageInHandlerPre40.java
@@ -59,9 +59,8 @@ public class MessageInHandlerPre40 extends
BaseMessageInHandler
{
super(peer, messagingVersion, messageConsumer);
-if (messagingVersion >= MessagingService.VERSION_40)
-throw new IllegalArgumentException(String.format("wrong messaging
version for this handler", messagingVersion));
-
+assert messagingVersion < MessagingService.VERSION_40 :
String.format("wrong messaging version for this handler: got %d, but expect
lower than %d",
+
messagingVersion, MessagingService.VERSION_40);
state = State.READ_FIRST_CHUNK;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9abeff38/test/unit/org/apache/cassandra/net/async/MessageInHandlerTest.java
--
diff --git a/test/unit/org/apache/cassandra/net/async/MessageInHandlerTest.java
b/test/unit/org/apache/cassandra/net/async/MessageInHandlerTest.java
index 16f4faf..8deb6dc 100644
--- a/test/unit/org/apache/cassandra/net/async/MessageInHandlerTest.java
+++ b/test/unit/org/apache/cassandra/net/async/MessageInHandlerTest.java
@@ -92,11 +92,19 @@ public class MessageInHandlerTest
private BaseMessageInHandler getHandler(InetAddressAndPort addr, int
messagingVersion, BiConsumer messageConsumer)
{
-if (messagingVersion >= MessagingService.VERSION_40)
-return new MessageInHandler(addr, messagingVersion,
messageConsumer);
-return
[jira] [Updated] (CASSANDRA-14576) Improve logging in MessageInHandler's constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-14576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-14576: - Reviewer: Dinesh Joshi > Improve logging in MessageInHandler's constructor > - > > Key: CASSANDRA-14576 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14576 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Trivial > Fix For: 4.0 > > > There's a minor logging bug in when when complaining about unacceptable > messaging version in MessageInHandler's constructor. The passed in version > does not get logged (even though it should). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14576) Improve logging in MessageInHandler's constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-14576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551415#comment-16551415 ] Dinesh Joshi commented on CASSANDRA-14576: -- +1 LGTM. Thank you for including tests. > Improve logging in MessageInHandler's constructor > - > > Key: CASSANDRA-14576 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14576 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Trivial > Fix For: 4.0 > > > There's a minor logging bug in when when complaining about unacceptable > messaging version in MessageInHandler's constructor. The passed in version > does not get logged (even though it should). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13693) A potential problem in the Ec2MultiRegionSnitch_gossiperStarting method
[
https://issues.apache.org/jira/browse/CASSANDRA-13693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella reassigned CASSANDRA-13693:
Assignee: (was: Vinay Chella)
> A potential problem in the Ec2MultiRegionSnitch_gossiperStarting method
> ---
>
> Key: CASSANDRA-13693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13693
> Project: Cassandra
> Issue Type: Bug
> Components: Distributed Metadata
>Reporter: Hao Zhong
>Priority: Major
>
> The code of Ec2MultiRegionSnitch_gossiperStarting is as follow:
> {code}
> public void gossiperStarting()
> {
> super.gossiperStarting();
>
> Gossiper.instance.addLocalApplicationState(ApplicationState.INTERNAL_IP,
> StorageService.instance.valueFactory.internalIP(localPrivateAddress));
> Gossiper.instance.register(new ReconnectableSnitchHelper(this,
> ec2region, true));
> }
> {code}
> I notice that CASSANDRA-5897 fixed a bug, whose buggy code is identical. The
> fixed code is
> {code}
> public void gossiperStarting()
> {
> super.gossiperStarting();
>
> Gossiper.instance.addLocalApplicationState(ApplicationState.INTERNAL_IP,
>
> StorageService.instance.valueFactory.internalIP(FBUtilities.getLocalAddress().getHostAddress()));
> reloadGossiperState();
> gossipStarted = true;
> }
> private void reloadGossiperState()
> {
> if (Gossiper.instance != null)
> {
> ReconnectableSnitchHelper pendingHelper = new
> ReconnectableSnitchHelper(this, myDC, preferLocal);
> Gossiper.instance.register(pendingHelper);
>
> pendingHelper = snitchHelperReference.getAndSet(pendingHelper);
> if (pendingHelper != null)
> Gossiper.instance.unregister(pendingHelper);
> }
> // else this will eventually rerun at gossiperStarting()
> }
> {code}
> If Ec2MultiRegionSnitch is supposed to auto-reload, the above fix shall be
> applied to its code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13693) A potential problem in the Ec2MultiRegionSnitch_gossiperStarting method
[
https://issues.apache.org/jira/browse/CASSANDRA-13693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella reassigned CASSANDRA-13693:
Assignee: Vinay Chella
> A potential problem in the Ec2MultiRegionSnitch_gossiperStarting method
> ---
>
> Key: CASSANDRA-13693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13693
> Project: Cassandra
> Issue Type: Bug
> Components: Distributed Metadata
>Reporter: Hao Zhong
>Assignee: Vinay Chella
>Priority: Major
>
> The code of Ec2MultiRegionSnitch_gossiperStarting is as follow:
> {code}
> public void gossiperStarting()
> {
> super.gossiperStarting();
>
> Gossiper.instance.addLocalApplicationState(ApplicationState.INTERNAL_IP,
> StorageService.instance.valueFactory.internalIP(localPrivateAddress));
> Gossiper.instance.register(new ReconnectableSnitchHelper(this,
> ec2region, true));
> }
> {code}
> I notice that CASSANDRA-5897 fixed a bug, whose buggy code is identical. The
> fixed code is
> {code}
> public void gossiperStarting()
> {
> super.gossiperStarting();
>
> Gossiper.instance.addLocalApplicationState(ApplicationState.INTERNAL_IP,
>
> StorageService.instance.valueFactory.internalIP(FBUtilities.getLocalAddress().getHostAddress()));
> reloadGossiperState();
> gossipStarted = true;
> }
> private void reloadGossiperState()
> {
> if (Gossiper.instance != null)
> {
> ReconnectableSnitchHelper pendingHelper = new
> ReconnectableSnitchHelper(this, myDC, preferLocal);
> Gossiper.instance.register(pendingHelper);
>
> pendingHelper = snitchHelperReference.getAndSet(pendingHelper);
> if (pendingHelper != null)
> Gossiper.instance.unregister(pendingHelper);
> }
> // else this will eventually rerun at gossiperStarting()
> }
> {code}
> If Ec2MultiRegionSnitch is supposed to auto-reload, the above fix shall be
> applied to its code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-14579) Set broadcast address in internode messagaing handshake
[
https://issues.apache.org/jira/browse/CASSANDRA-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Brown resolved CASSANDRA-14579.
-
Resolution: Fixed
Assignee: Ariel Weisberg (was: Jason Brown)
Reviewer: Jason Brown (was: Ariel Weisberg)
Fix Version/s: (was: 4.x)
4.0
committed as sha {{c4263d26b43a4a65a31f213a10f6fbd68217825c}}. Thanks,
[~aweisberg]
> Set broadcast address in internode messagaing handshake
> ---
>
> Key: CASSANDRA-14579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14579
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Ariel Weisberg
>Priority: Major
> Fix For: 4.0
>
>
> I am incorrectly setting the local address into the internode messaging
> handshake, rather than the broadcast address. This bug existed since
> CASSANDRA-8457, but had no effect until CASSANDRA-14485. Originally
> discovered by [~aweisberg].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
cassandra git commit: Set broadcast address in internode messaging handshake
Repository: cassandra Updated Branches: refs/heads/trunk 13150b001 -> c4263d26b Set broadcast address in internode messaging handshake patch by Ariel Weisberg; reviewed by jasobrown for CASSANDRA-14579 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c4263d26 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c4263d26 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c4263d26 Branch: refs/heads/trunk Commit: c4263d26b43a4a65a31f213a10f6fbd68217825c Parents: 13150b0 Author: Ariel Weisberg Authored: Fri Jul 20 14:27:12 2018 -0700 Committer: Jason Brown Committed: Fri Jul 20 15:19:51 2018 -0700 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/net/MessagingService.java | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c4263d26/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index fe4087b..4b53c03 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0 + * Set broadcast address in internode messaging handshake (CASSANDRA-14579) * Wait for schema agreement prior to building MVs (CASSANDRA-14571) * Make all DDL statements idempotent and not dependent on global state (CASSANDRA-13426) * Bump the hints messaging version to match the current one (CASSANDRA-14536) http://git-wip-us.apache.org/repos/asf/cassandra/blob/c4263d26/src/java/org/apache/cassandra/net/MessagingService.java -- diff --git a/src/java/org/apache/cassandra/net/MessagingService.java b/src/java/org/apache/cassandra/net/MessagingService.java index f5051fb..b2e72f4 100644 --- a/src/java/org/apache/cassandra/net/MessagingService.java +++ b/src/java/org/apache/cassandra/net/MessagingService.java @@ -1633,7 +1633,7 @@ public final class MessagingService implements MessagingServiceMBean return null; InetAddressAndPort preferredRemote = SystemKeyspace.getPreferredIP(to); -InetAddressAndPort local = FBUtilities.getLocalAddressAndPort(); +InetAddressAndPort local = FBUtilities.getBroadcastAddressAndPort(); ServerEncryptionOptions encryptionOptions = secure ? DatabaseDescriptor.getInternodeMessagingEncyptionOptions() : null; IInternodeAuthenticator authenticator = DatabaseDescriptor.getInternodeAuthenticator(); - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14579) Set broadcast address in internode messagaing handshake
[ https://issues.apache.org/jira/browse/CASSANDRA-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551331#comment-16551331 ] Ariel Weisberg commented on CASSANDRA-14579: +1 This fix has been working for me and when I researched things this is what we used in prior versions for this message. > Set broadcast address in internode messagaing handshake > --- > > Key: CASSANDRA-14579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14579 > Project: Cassandra > Issue Type: Bug >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Major > Fix For: 4.x > > > I am incorrectly setting the local address into the internode messaging > handshake, rather than the broadcast address. This bug existed since > CASSANDRA-8457, but had no effect until CASSANDRA-14485. Originally > discovered by [~aweisberg]. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14579) Set broadcast address in internode messagaing handshake
[ https://issues.apache.org/jira/browse/CASSANDRA-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-14579: --- Reviewer: Ariel Weisberg > Set broadcast address in internode messagaing handshake > --- > > Key: CASSANDRA-14579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14579 > Project: Cassandra > Issue Type: Bug >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Major > Fix For: 4.x > > > I am incorrectly setting the local address into the internode messaging > handshake, rather than the broadcast address. This bug existed since > CASSANDRA-8457, but had no effect until CASSANDRA-14485. Originally > discovered by [~aweisberg]. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14579) Set broadcast address in internode messagaing handshake
[ https://issues.apache.org/jira/browse/CASSANDRA-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551314#comment-16551314 ] Jason Brown commented on CASSANDRA-14579: - One-liner fix here: ||14579|| |[branch|https://github.com/jasobrown/cassandra/tree/14579]| |[utests dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14579]| || > Set broadcast address in internode messagaing handshake > --- > > Key: CASSANDRA-14579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14579 > Project: Cassandra > Issue Type: Bug >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Major > Fix For: 4.x > > > I am incorrectly setting the local address into the internode messaging > handshake, rather than the broadcast address. This bug existed since > CASSANDRA-8457, but had no effect until CASSANDRA-14485. Originally > discovered by [~aweisberg]. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14579) Set broadcast address in internode messagaing handshake
[ https://issues.apache.org/jira/browse/CASSANDRA-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-14579: Description: I am incorrectly setting the local address into the internode messaging handshake, rather than the broadcast address. This bug existed since CASSANDRA-8457, but had no effect until CASSANDRA-14485. Originally discovered by [~aweisberg]. (was: I am incorrectly setting the local address into the internode messaging handshake, rather than the broadcast address. This bug existed since CASSANDRA-8457, but had no effect until CASSANDRA-14485.) > Set broadcast address in internode messagaing handshake > --- > > Key: CASSANDRA-14579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14579 > Project: Cassandra > Issue Type: Bug >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Major > Fix For: 4.x > > > I am incorrectly setting the local address into the internode messaging > handshake, rather than the broadcast address. This bug existed since > CASSANDRA-8457, but had no effect until CASSANDRA-14485. Originally > discovered by [~aweisberg]. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14579) Set broadcast address in internode messagaing handshake
Jason Brown created CASSANDRA-14579: --- Summary: Set broadcast address in internode messagaing handshake Key: CASSANDRA-14579 URL: https://issues.apache.org/jira/browse/CASSANDRA-14579 Project: Cassandra Issue Type: Bug Reporter: Jason Brown Assignee: Jason Brown Fix For: 4.x I am incorrectly setting the local address into the internode messaging handshake, rather than the broadcast address. This bug existed since CASSANDRA-8457, but had no effect until CASSANDRA-14485. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14578) Add optional checksumming to internode messaging
Jason Brown created CASSANDRA-14578: --- Summary: Add optional checksumming to internode messaging Key: CASSANDRA-14578 URL: https://issues.apache.org/jira/browse/CASSANDRA-14578 Project: Cassandra Issue Type: Improvement Reporter: Jason Brown Similar to CASSANDRA-13304, we should add (optional) checksumming to the internode messaging protocol. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10540) RangeAwareCompaction
[ https://issues.apache.org/jira/browse/CASSANDRA-10540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-10540: - Labels: 4.0-feature-freeze-review-requested compaction lcs vnodes (was: compaction lcs vnodes) > RangeAwareCompaction > > > Key: CASSANDRA-10540 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10540 > Project: Cassandra > Issue Type: New Feature >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Major > Labels: 4.0-feature-freeze-review-requested, compaction, lcs, > vnodes > Fix For: 4.x > > > Broken out from CASSANDRA-6696, we should split sstables based on ranges > during compaction. > Requirements; > * dont create tiny sstables - keep them bunched together until a single vnode > is big enough (configurable how big that is) > * make it possible to run existing compaction strategies on the per-range > sstables > We should probably add a global compaction strategy parameter that states > whether this should be enabled or not. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14291) Nodetool command to recreate SSTable components
[
https://issues.apache.org/jira/browse/CASSANDRA-14291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14291:
-
Labels: 4.0-feature-freeze-review-requested (was: )
> Nodetool command to recreate SSTable components
> ---
>
> Key: CASSANDRA-14291
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14291
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Kurt Greaves
>Assignee: Alexander Ivakov
>Priority: Minor
> Labels: 4.0-feature-freeze-review-requested
>
> Need a JMX/Nodetool command to recreate components for SSTables without
> re-writing the data files.
> Possible implementation idea:
> Create a {{nodetool (recreate|regen)component}} command that would enable you
> to recreate specific components of an SSTable, and also allow specifying
> SSTables or columnfamilies.
> I'd say a flag for a list of components and a flag for SSTables with
> keyspace.columnfamilies as positional arguments would work
> Alternatively this could become part of upgradesstables, but would likely
> make that command a bit bloated.
> Background:
> In CASSANDRA-11163 we changed it so summaries and bloomfilters were not
> regenerated or persisted on startup. This means we would rely on
> compactions/upgrades to regenerate the bloomfilter (or other components)
> after a configuration change. While this works, it's pretty inefficient on
> large tables just because you changed the bloomfilter size or summary chunk
> sizes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12783) Break up large MV mutations to prevent OOMs
[ https://issues.apache.org/jira/browse/CASSANDRA-12783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-12783: - Labels: 4.0-feature-freeze-review-requested (was: ) > Break up large MV mutations to prevent OOMs > --- > > Key: CASSANDRA-12783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12783 > Project: Cassandra > Issue Type: Bug > Components: Local Write-Read Paths, Materialized Views >Reporter: Carl Yeksigian >Assignee: Kurt Greaves >Priority: Major > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > We only use the code path added in CASSANDRA-12268 for the view builder > because otherwise we would break the contract of the batchlog, where some > mutations may be written and pushed out before the whole batch log has been > saved. > We would need to ensure that all of the updates make it to the batchlog > before allowing the batchlog manager to try to replay them, but also before > we start pushing out updates to the paired replicas. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13841) Allow specific sources during rebuild
[
https://issues.apache.org/jira/browse/CASSANDRA-13841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-13841:
-
Labels: 4.0-feature-freeze-review-requested (was: )
> Allow specific sources during rebuild
> -
>
> Key: CASSANDRA-13841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13841
> Project: Cassandra
> Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
>Priority: Minor
> Labels: 4.0-feature-freeze-review-requested
>
> CASSANDRA-10406 introduced the ability to rebuild specific ranges, and
> CASSANDRA-9875 extended that to allow specifying a set of hosts to stream
> from. It's not incredibly clear why you would only want to stream a subset of
> ranges, but a possible use case for this functionality is to rebuild a node
> from targeted replicas.
> When doing a DC migration, if you are using racks==RF while rebuilding you
> can ensure you rebuild from each copy of a replica in the source datacenter
> by specifying all the hosts from a single rack to rebuild a single copy from.
> This can be repeated for each rack in the new datacenter to ensure you have
> each copy of the replica from the source DC, and thus maintaining consistency
> through rebuilds.
> For example, with the following topology for DC A and B with an RF of A:3 and
> B:3
> ||A ||B||
> ||Node||Rack||Node||Rack||
> |A1|rack1| B1|rack1|
> |A2|rack2| B2|rack2|
> |A3|rack3| B3|rack3|
> The following set of actions will result in having exactly 1 copy of every
> replica in A in B, and B will be _at least_ as consistent as A.
> {code:java}
> Rebuild B1 from only A1
> Rebuild B2 from only A2
> Rebuild B3 from only A3
> {code}
> Unfortunately using this functionality is non-trivial at the moment, as you
> can only specify specific sources WITH the nodes set of tokens to rebuild
> from. To perform the above with vnodes/a large cluster, you will have to
> specify every token range in the -ts arg, which quickly gets
> unwieldy/impossible if you have a large cluster.
> A solution to this is to simply filter on sources first, before processing
> ranges.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14309) Make hint window persistent across restarts
[
https://issues.apache.org/jira/browse/CASSANDRA-14309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14309:
-
Labels: 4.0-feature-freeze-review-requested (was: )
> Make hint window persistent across restarts
> ---
>
> Key: CASSANDRA-14309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14309
> Project: Cassandra
> Issue Type: Improvement
> Components: Hints
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
>Priority: Minor
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
>
> The current hint system stores a window of hints as defined by
> {{max_hint_window_in_ms}}, however this window is not persistent across
> restarts.
> Examples (cluster with RF=3 and 3 nodes, A, B, and C):
> # A goes down
> # X ms of hints are stored for A on B and C
> # A is restarted
> # A goes down again without hints replaying from B and C
> # B and C will store up to another {{max_hint_window_in_ms}} of hints for A
>
> # A goes down
> # X ms of hints are stored for A on B and C
> # B is restarted
> # B will store up to another {{max_hint_window_in_ms}} of hints for A
>
> Note that in both these scenarios they can continue forever. If A or B keeps
> getting restarted hints will continue to pile up.
>
> Idea of this ticket is to stop this behaviour from happening and only ever
> store up to {{max_hint_window_in_ms}} of hints for a particular node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10789) Allow DBAs to kill individual client sessions from certain IP(s) and temporarily block subsequent connections without bouncing JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-10789: - Labels: 4.0-feature-freeze-review-requested (was: ) > Allow DBAs to kill individual client sessions from certain IP(s) and > temporarily block subsequent connections without bouncing JVM > -- > > Key: CASSANDRA-10789 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10789 > Project: Cassandra > Issue Type: Improvement > Components: Coordination >Reporter: Wei Deng >Assignee: Damien Stevenson >Priority: Major > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > Attachments: 10789-trunk-dtest.txt, 10789-trunk.txt > > > In production, there could be hundreds of clients connected to a Cassandra > cluster (maybe even from different applications), and if they use DataStax > Java Driver, each client will establish at least one TCP connection to a > Cassandra server (see > https://datastax.github.io/java-driver/2.1.9/features/pooling/). This is all > normal and at any given time, you can indeed see hundreds of ESTABLISHED > connections to port 9042 on a C* server (from netstat -na). The problem is > that sometimes when a C* cluster is under heavy load, when the DBA identifies > some client session that sends abusive amount of traffic to the C* server and > would like to stop it, they would like a lightweight approach rather than > shutting down the JVM or rolling restart the whole cluster to kill all > hundreds of connections in order to kill a single client session. If the DBA > had root privilege, they would have been able to do something at the OS > network level to achieve the same goal but oftentimes enterprise DBA role is > separate from OS sysadmin role, so the DBAs usually don't have that privilege. > This is especially helpful when you have a multi-tenant C* cluster and you > want to have the impact for handling such client to be minimal to the other > applications. This feature (killing individual session) seems to be a common > feature in other databases (regardless of whether the client has some > reconnect logic or not). It could be implemented as a JMX MBean method and > exposed through nodetool to the DBAs. > Note due to CQL driver's automated reconnection, simply killing the currently > connected client session will not work well, so the JMX parameter should be > an IP address or a list of IP addresses, so that the Cassandra server can > terminate existing connection with that IP, and block future connection > attempts from that IP for the remaining time until the JVM is restarted. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14358) OutboundTcpConnection can hang for many minutes when nodes restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14358:
-
Labels: 4.0-feature-freeze-review-requested (was: )
> OutboundTcpConnection can hang for many minutes when nodes restart
> --
>
> Key: CASSANDRA-14358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14358
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
> Environment: Cassandra 2.1.19 (also reproduced on 3.0.15), running
> with {{internode_encryption: all}} and the EC2 multi region snitch on Linux
> 4.13 within the same AWS region. Smallest cluster I've seen the problem on is
> 12 nodes, reproduces more reliably on 40+ and 300 node clusters consistently
> reproduce on at least one node in the cluster.
> So all the connections are SSL and we're connecting on the internal ip
> addresses (not the public endpoint ones).
> Potentially relevant sysctls:
> {noformat}
> /proc/sys/net/ipv4/tcp_syn_retries = 2
> /proc/sys/net/ipv4/tcp_synack_retries = 5
> /proc/sys/net/ipv4/tcp_keepalive_time = 7200
> /proc/sys/net/ipv4/tcp_keepalive_probes = 9
> /proc/sys/net/ipv4/tcp_keepalive_intvl = 75
> /proc/sys/net/ipv4/tcp_retries2 = 15
> {noformat}
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Major
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
> Attachments: 10 Minute Partition.pdf
>
>
> edit summary: This primarily impacts networks with stateful firewalls such as
> AWS. I'm working on a proper patch for trunk but unfortunately it relies on
> the Netty refactor in 4.0 so it will be hard to backport to previous
> versions. A workaround for earlier versions is to set the
> {{net.ipv4.tcp_retries2}} sysctl to ~5. This can be done with the following:
> {code:java}
> $ cat /etc/sysctl.d/20-cassandra-tuning.conf
> net.ipv4.tcp_retries2=5
> $ # Reload all sysctls
> $ sysctl --system{code}
> Original Bug Report:
> I've been trying to debug nodes not being able to see each other during
> longer (~5 minute+) Cassandra restarts in 3.0.x and 2.1.x which can
> contribute to {{UnavailableExceptions}} during rolling restarts of 3.0.x and
> 2.1.x clusters for us. I think I finally have a lead. It appears that prior
> to trunk (with the awesome Netty refactor) we do not set socket connect
> timeouts on SSL connections (in 2.1.x, 3.0.x, or 3.11.x) nor do we set
> {{SO_TIMEOUT}} as far as I can tell on outbound connections either. I believe
> that this means that we could potentially block forever on {{connect}} or
> {{recv}} syscalls, and we could block forever on the SSL Handshake as well. I
> think that the OS will protect us somewhat (and that may be what's causing
> the eventual timeout) but I think that given the right network conditions our
> {{OutboundTCPConnection}} threads can just be stuck never making any progress
> until the OS intervenes.
> I have attached some logs of such a network partition during a rolling
> restart where an old node in the cluster has a completely foobarred
> {{OutboundTcpConnection}} for ~10 minutes before finally getting a
> {{java.net.SocketException: Connection timed out (Write failed)}} and
> immediately successfully reconnecting. I conclude that the old node is the
> problem because the new node (the one that restarted) is sending ECHOs to the
> old node, and the old node is sending ECHOs and REQUEST_RESPONSES to the new
> node's ECHOs, but the new node is never getting the ECHO's. This appears, to
> me, to indicate that the old node's {{OutboundTcpConnection}} thread is just
> stuck and can't make any forward progress. By the time we could notice this
> and slap TRACE logging on, the only thing we see is ~10 minutes later a
> {{SocketException}} inside {{writeConnected}}'s flush and an immediate
> recovery. It is interesting to me that the exception happens in
> {{writeConnected}} and it's a _connection timeout_ (and since we see {{Write
> failure}} I believe that this can't be a connection reset), because my
> understanding is that we should have a fully handshaked SSL connection at
> that point in the code.
> Current theory:
> # "New" node restarts, "Old" node calls
> [newSocket|https://github.com/apache/cassandra/blob/6f30677b28dcbf82bcd0a291f3294ddf87dafaac/src/java/org/apache/cassandra/net/OutboundTcpConnection.java#L433]
> # Old node starts [creating a
> new|https://github.com/apache/cassandra/blob/6f30677b28dcbf82bcd0a291f3294ddf87dafaac/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java#L141]
> SSL socket
> # SSLSocket calls
>
[jira] [Updated] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-13010: - Labels: 4.0-feature-freeze-review-requested lhf (was: lhf) > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: 4.0-feature-freeze-review-requested, lhf > Attachments: cleanup.png, multiple operations.png > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14346) Scheduled Repair in Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-14346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14346: - Labels: 4.0-feature-freeze-review-requested CommunityFeedbackRequested (was: CommunityFeedbackRequested) > Scheduled Repair in Cassandra > - > > Key: CASSANDRA-14346 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14346 > Project: Cassandra > Issue Type: Improvement > Components: Repair >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Major > Labels: 4.0-feature-freeze-review-requested, > CommunityFeedbackRequested > Fix For: 4.0 > > Attachments: ScheduledRepairV1_20180327.pdf > > > There have been many attempts to automate repair in Cassandra, which makes > sense given that it is necessary to give our users eventual consistency. Most > recently CASSANDRA-10070, CASSANDRA-8911 and CASSANDRA-13924 have all looked > for ways to solve this problem. > At Netflix we've built a scheduled repair service within Priam (our sidecar), > which we spoke about last year at NGCC. Given the positive feedback at NGCC > we focussed on getting it production ready and have now been using it in > production to repair hundreds of clusters, tens of thousands of nodes, and > petabytes of data for the past six months. Also based on feedback at NGCC we > have invested effort in figuring out how to integrate this natively into > Cassandra rather than open sourcing it as an external service (e.g. in Priam). > As such, [~vinaykumarcse] and I would like to re-work and merge our > implementation into Cassandra, and have created a [design > document|https://docs.google.com/document/d/1RV4rOrG1gwlD5IljmrIq_t45rz7H3xs9GbFSEyGzEtM/edit?usp=sharing] > showing how we plan to make it happen, including the the user interface. > As we work on the code migration from Priam to Cassandra, any feedback would > be greatly appreciated about the interface or v1 implementation features. I > have tried to call out in the document features which we explicitly consider > future work (as well as a path forward to implement them in the future) > because I would very much like to get this done before the 4.0 merge window > closes, and to do that I think aggressively pruning scope is going to be a > necessity. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-10023: - Labels: 4.0-feature-freeze-review-requested lhf (was: lhf) > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: Damien Stevenson >Priority: Minor > Labels: 4.0-feature-freeze-review-requested, lhf > Fix For: 4.x > > Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, > CASSANDRA-10023.patch > > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-9452) Remove configuration of storage-conf from tools
[ https://issues.apache.org/jira/browse/CASSANDRA-9452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-9452: Labels: 4.0-feature-freeze-review-requested lhf (was: lhf) > Remove configuration of storage-conf from tools > --- > > Key: CASSANDRA-9452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9452 > Project: Cassandra > Issue Type: Task > Components: Configuration, Testing, Tools >Reporter: Mike Adamson >Assignee: Vinay Chella >Priority: Minor > Labels: 4.0-feature-freeze-review-requested, lhf > Fix For: 4.x > > Attachments: CASSANDRA-14092-trunk_v1.txt, CASSANDRA-9452-trunk.txt > > > The following files still making reference to storage-config and/or > storage-conf.xml > * ./build.xml > * ./bin/nodetool > * ./bin/sstablekeys > * ./test/resources/functions/configure_cassandra.sh > * ./test/resources/functions/install_cassandra.sh > * ./tools/bin/json2sstable > * ./tools/bin/sstable2json > * ./tools/bin/sstablelevelreset -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14297) Optional startup delay for peers should wait for count rather than percentage
[
https://issues.apache.org/jira/browse/CASSANDRA-14297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14297:
-
Labels: 4.0-feature-freeze-review-requested PatchAvailable (was:
PatchAvailable)
> Optional startup delay for peers should wait for count rather than percentage
> -
>
> Key: CASSANDRA-14297
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14297
> Project: Cassandra
> Issue Type: Improvement
> Components: Lifecycle
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Minor
> Labels: 4.0-feature-freeze-review-requested, PatchAvailable
>
> As I commented in CASSANDRA-13993, the current wait for functionality is a
> great step in the right direction, but I don't think that the current setting
> (70% of nodes in the cluster) is the right configuration option. First I
> think this because 70% will not protect against errors as if you wait for 70%
> of the cluster you could still very easily have {{UnavailableException}} or
> {{ReadTimeoutException}} exceptions. This is because if you have even two
> nodes down in different racks in a Cassandra cluster these exceptions are
> possible (or with the default {{num_tokens}} setting of 256 it is basically
> guaranteed). Second I think this option is not easy for operators to set, the
> only setting I could think of that would "just work" is 100%.
> I proposed in that ticket instead of having `block_for_peers_percentage`
> defaulting to 70%, we instead have `block_for_peers` as a count of nodes that
> are allowed to be down before the starting node makes itself available as a
> coordinator. Of course, we would still have the timeout to limit startup time
> and deal with really extreme situations (whole datacenters down etc).
> I started working on a patch for this change [on
> github|https://github.com/jasobrown/cassandra/compare/13993...jolynch:13993],
> and am happy to finish it up with unit tests and such if someone can
> review/commit it (maybe [~aweisberg]?).
> I think the short version of my proposal is we replace:
> {noformat}
> block_for_peers_percentage:
> {noformat}
> with either
> {noformat}
> block_for_peers:
> {noformat}
> or, if we want to do even better imo and enable advanced operators to finely
> tune this behavior (while still having good defaults that work for almost
> everyone):
> {noformat}
> block_for_peers_local_dc:
> block_for_peers_each_dc:
> block_for_peers_all_dcs:
> {noformat}
> For example if an operator knows that they must be available at
> {{LOCAL_QUORUM}} they would set {{block_for_peers_local_dc=1}}, if they use
> {{EACH_QUOURM}} they would set {{block_for_peers_local_dc=1}}, if they use
> {{QUORUM}} (RF=3, dcs=2) they would set {{block_for_peers_all_dcs=2}}.
> Naturally everything would of course have a timeout to prevent startup taking
> too long.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14557:
-
Labels: 4.0-feature-freeze-review-requested (was: )
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.0
>
> Attachments: 14557-trunk.txt
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14459) DynamicEndpointSnitch should never prefer latent nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14459:
-
Labels: 4.0-feature-freeze-review-requested (was: )
> DynamicEndpointSnitch should never prefer latent nodes
> --
>
> Key: CASSANDRA-14459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14459
> Project: Cassandra
> Issue Type: Improvement
> Components: Coordination
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Minor
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
>
> The DynamicEndpointSnitch has two unfortunate behaviors that allow it to
> provide latent hosts as replicas:
> # Loses all latency information when Cassandra restarts
> # Clears latency information entirely every ten minutes (by default),
> allowing global queries to be routed to _other datacenters_ (and local
> queries cross racks/azs)
> This means that the first few queries after restart/reset could be quite slow
> compared to average latencies. I propose we solve this by resetting to the
> minimum observed latency instead of completely clearing the samples and
> extending the {{isLatencyForSnitch}} idea to a three state variable instead
> of two, in particular {{YES}}, {{NO}}, {{MAYBE}}. This extension allows
> {{EchoMessages}} and {{PingMessages}} to send {{MAYBE}} indicating that the
> DS should use those measurements if it only has one or fewer samples for a
> host. This fixes both problems because on process restart we send out
> {{PingMessages}} / {{EchoMessages}} as part of startup, and we would reset to
> effectively the RTT of the hosts (also at that point normal gossip
> {{EchoMessages}} have an opportunity to add an additional latency
> measurement).
> This strategy also nicely deals with the "a host got slow but now it's fine"
> problem that the DS resets were (afaik) designed to stop because the
> {{EchoMessage}} ping latency will count only after the reset for that host.
> Ping latency is a more reasonable lower bound on host latency (as opposed to
> status quo of zero).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14303) NetworkTopologyStrategy could have a "default replication" option
[
https://issues.apache.org/jira/browse/CASSANDRA-14303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14303:
-
Labels: 4.0-feature-freeze-review-requested (was: )
> NetworkTopologyStrategy could have a "default replication" option
> -
>
> Key: CASSANDRA-14303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14303
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Minor
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.0
>
>
> Right now when creating a keyspace with {{NetworkTopologyStrategy}} the user
> has to manually specify the datacenters they want their data replicated to
> with parameters, e.g.:
> {noformat}
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': 3, 'dc2': 3}{noformat}
> This is a poor user interface because it requires the creator of the keyspace
> (typically a developer) to know the layout of the Cassandra cluster (which
> may or may not be controlled by them). Also, at least in my experience, folks
> typo the datacenters _all_ the time. To work around this I see a number of
> users creating automation around this where the automation describes the
> Cassandra cluster and automatically expands out to all the dcs that Cassandra
> knows about. Why can't Cassandra just do this for us, re-using the previously
> forbidden {{replication_factor}} option (for backwards compatibility):
> {noformat}
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'replication_factor': 3}{noformat}
> This would automatically replicate this Keyspace to all datacenters that are
> present in the cluster. If you need to _override_ the default you could
> supply a datacenter name, e.g.:
> {noformat}
> > CREATE KEYSPACE test WITH replication = {'class':
> > 'NetworkTopologyStrategy', 'replication_factor': 3, 'dc1': 2}
> > DESCRIBE KEYSPACE test
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': '2', 'dc2': 3} AND durable_writes = true;
> {noformat}
> On the implementation side I think this may be reasonably straightforward to
> do an auto-expansion at the time of keyspace creation (or alter), where the
> above would automatically expand to list out the datacenters. We could allow
> this to be recomputed whenever an AlterKeyspaceStatement runs so that to add
> datacenters you would just run:
> {noformat}
> ALTER KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'replication_factor': 3}{noformat}
> and this would check that if the dc's in the current schema are different you
> add in the new ones (_for safety reasons we'd never remove non explicitly
> supplied zero dcs when auto-generating dcs_). Removing a datacenter becomes
> an alter that includes an override for the dc you want to remove (or of
> course you can always not use the auto-expansion and just use the old way):
> {noformat}
> // Tell it explicitly not to replicate to dc2
> > ALTER KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> > 'replication_factor': 3, 'dc2': 0}
> > DESCRIBE KEYSPACE test
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': '3'} AND durable_writes = true;{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13701) Lower default num_tokens
[ https://issues.apache.org/jira/browse/CASSANDRA-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551241#comment-16551241 ] Sumanth Pasupuleti edited comment on CASSANDRA-13701 at 7/20/18 8:37 PM: - [CASSANDRA-14557 |https://issues.apache.org/jira/browse/CASSANDRA-14557] adds default_keyspace_rf to yaml that could possibly serve the purpose [~KurtG] is referring to, in the above comment. was (Author: sumanth.pasupuleti): [CASSANDRA-14557 |https://issues.apache.org/jira/browse/CASSANDRA-14557] adds default_keyspace_rf that could possibly serve the purpose [~KurtG] is referring to, in the above comment. > Lower default num_tokens > > > Key: CASSANDRA-13701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13701 > Project: Cassandra > Issue Type: Improvement >Reporter: Chris Lohfink >Priority: Minor > > For reasons highlighted in CASSANDRA-7032, the high number of vnodes is not > necessary. It is very expensive for operations processes and scanning. Its > come up a lot and its pretty standard and known now to always reduce the > num_tokens within the community. We should just lower the defaults. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13701) Lower default num_tokens
[ https://issues.apache.org/jira/browse/CASSANDRA-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551241#comment-16551241 ] Sumanth Pasupuleti commented on CASSANDRA-13701: [CASSANDRA-14557 |https://issues.apache.org/jira/browse/CASSANDRA-14557] adds default_keyspace_rf that could possibly serve the purpose [~KurtG] is referring to, in the above comment. > Lower default num_tokens > > > Key: CASSANDRA-13701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13701 > Project: Cassandra > Issue Type: Improvement >Reporter: Chris Lohfink >Priority: Minor > > For reasons highlighted in CASSANDRA-7032, the high number of vnodes is not > necessary. It is very expensive for operations processes and scanning. Its > come up a lot and its pretty standard and known now to always reduce the > num_tokens within the community. We should just lower the defaults. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14575) Reevaluate when to drop an internode connection on message error
[
https://issues.apache.org/jira/browse/CASSANDRA-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551232#comment-16551232
]
Dinesh Joshi commented on CASSANDRA-14575:
--
Hi [~jasobrown], I think catching {{UnknownTableException}} in the Networking
code and handling it as one off issue should be avoided. We should ideally
catch any exception during Decoding and move on to the next message in the
pipeline. In doing so, we should keep a counter of the number of contiguous
corrupt messages we've seen. If we hit a certain threshold, we close the
channel and move on. This is to protect us from situations where there is a bit
flip in the fields leading to corruption of the whole data stream (our
internode messages are not currently checksummed so we're at risk of running
into this issue). This is also generic enough so any application level
exceptions do not affect the decoding pipeline. We should also try validating
the incoming states as this is a state machine. This is more to protect us from
future changes to the decoding method that may lead to invalid state
transitions. WDYT?
> Reevaluate when to drop an internode connection on message error
>
>
> Key: CASSANDRA-14575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14575
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 4.0
>
>
> As mentioned in CASSANDRA-14574, explore if and when we can safely ignore an
> incoming internode message on certain classes of failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14575) Reevaluate when to drop an internode connection on message error
[ https://issues.apache.org/jira/browse/CASSANDRA-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-14575: - Reviewer: Dinesh Joshi > Reevaluate when to drop an internode connection on message error > > > Key: CASSANDRA-14575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14575 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Minor > Fix For: 4.0 > > > As mentioned in CASSANDRA-14574, explore if and when we can safely ignore an > incoming internode message on certain classes of failure. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551196#comment-16551196
]
Joseph Lynch commented on CASSANDRA-14557:
--
[~sumanth.pasupuleti] this looks pretty good to me, this will be super helpful
for users.
Comments on the patch:
* Consider making it clearer in the {{default_keyspace_rf}} cassandra.yaml
comments that users probably want 3 in production not 1 (also probably same for
minimum)
* Probably need some docs updates in {{doc/source/cql/ddl.rst}}
* Unit tests look good to me, have you done any ccm testing just to double
check the full e2e flow though? I think a dtest is probably overkill for such a
minor change but a few runs of ccm is probably worth it.
* Can we leave a breadcrumb on CASSANDRA-13701 that it could use this option?
* Can you run the unit tests and link the results here and when a committer
looks let's run dtests?
* Nitpick: You have some non style conforming comments in the tests (no space
between // and comment)
I think that the minimum validation still works with CASSANDRA-14303's strategy
for removing keyspaces where it uses zero since that removal happens before the
validation I believe.
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Fix For: 4.0
>
> Attachments: 14557-trunk.txt
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551196#comment-16551196
]
Joseph Lynch edited comment on CASSANDRA-14557 at 7/20/18 8:03 PM:
---
[~sumanth.pasupuleti] this looks pretty good to me, this will be super helpful
for users.
Comments on the patch:
* Consider making it clearer in the {{default_keyspace_rf}} cassandra.yaml
comments that users probably want 3 in production not 1 (also probably same for
minimum)
* Probably need some docs updates in {{doc/source/cql/ddl.rst}}
* Unit tests look good to me, have you done any ccm testing just to double
check the full e2e flow though? I think a dtest is probably overkill for such a
minor change but a few runs of ccm is probably worth it.
* Can we leave a breadcrumb on CASSANDRA-13701 that it could use this option?
* Nitpick: You have some non style conforming comments in the tests (no space
between // and comment)
I think that the minimum validation still works with CASSANDRA-14303's strategy
for removing keyspaces where it uses zero since that removal happens before the
validation I believe.
was (Author: jolynch):
[~sumanth.pasupuleti] this looks pretty good to me, this will be super helpful
for users.
Comments on the patch:
* Consider making it clearer in the {{default_keyspace_rf}} cassandra.yaml
comments that users probably want 3 in production not 1 (also probably same for
minimum)
* Probably need some docs updates in {{doc/source/cql/ddl.rst}}
* Unit tests look good to me, have you done any ccm testing just to double
check the full e2e flow though? I think a dtest is probably overkill for such a
minor change but a few runs of ccm is probably worth it.
* Can we leave a breadcrumb on CASSANDRA-13701 that it could use this option?
* Can you run the unit tests and link the results here and when a committer
looks let's run dtests?
* Nitpick: You have some non style conforming comments in the tests (no space
between // and comment)
I think that the minimum validation still works with CASSANDRA-14303's strategy
for removing keyspaces where it uses zero since that removal happens before the
validation I believe.
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Fix For: 4.0
>
> Attachments: 14557-trunk.txt
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14346) Scheduled Repair in Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-14346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella reassigned CASSANDRA-14346: Assignee: Joseph Lynch > Scheduled Repair in Cassandra > - > > Key: CASSANDRA-14346 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14346 > Project: Cassandra > Issue Type: Improvement > Components: Repair >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Major > Labels: CommunityFeedbackRequested > Fix For: 4.0 > > Attachments: ScheduledRepairV1_20180327.pdf > > > There have been many attempts to automate repair in Cassandra, which makes > sense given that it is necessary to give our users eventual consistency. Most > recently CASSANDRA-10070, CASSANDRA-8911 and CASSANDRA-13924 have all looked > for ways to solve this problem. > At Netflix we've built a scheduled repair service within Priam (our sidecar), > which we spoke about last year at NGCC. Given the positive feedback at NGCC > we focussed on getting it production ready and have now been using it in > production to repair hundreds of clusters, tens of thousands of nodes, and > petabytes of data for the past six months. Also based on feedback at NGCC we > have invested effort in figuring out how to integrate this natively into > Cassandra rather than open sourcing it as an external service (e.g. in Priam). > As such, [~vinaykumarcse] and I would like to re-work and merge our > implementation into Cassandra, and have created a [design > document|https://docs.google.com/document/d/1RV4rOrG1gwlD5IljmrIq_t45rz7H3xs9GbFSEyGzEtM/edit?usp=sharing] > showing how we plan to make it happen, including the the user interface. > As we work on the code migration from Priam to Cassandra, any feedback would > be greatly appreciated about the interface or v1 implementation features. I > have tried to call out in the document features which we explicitly consider > future work (as well as a path forward to implement them in the future) > because I would very much like to get this done before the 4.0 merge window > closes, and to do that I think aggressively pruning scope is going to be a > necessity. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551192#comment-16551192
]
Sumanth Pasupuleti commented on CASSANDRA-14557:
||trunk||
| patch [^14557-trunk.txt] |
|[github|https://github.com/sumanth-pasupuleti/cassandra/tree/CASSANDRA-14557]|
|[unit
tests|https://circleci.com/gh/sumanth-pasupuleti/cassandra/tree/CASSANDRA-14557]|
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Fix For: 4.0
>
> Attachments: 14557-trunk.txt
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14577) gc_grace_seconds should include UJ (Up/Joining) status period
[ https://issues.apache.org/jira/browse/CASSANDRA-14577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Knost updated CASSANDRA-14577: --- Environment: Contrail 3.0.3.3-22/Cassandra 2.1.13 (was: Issue observed in environment running Contrail 3.0.3.3-22/Cassandra 2.1.13) > gc_grace_seconds should include UJ (Up/Joining) status period > -- > > Key: CASSANDRA-14577 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14577 > Project: Cassandra > Issue Type: Improvement > Components: Coordination > Environment: Contrail 3.0.3.3-22/Cassandra 2.1.13 >Reporter: John Knost >Priority: Major > > Partial network connectivity (e.g. and MTU mismatch that blackholes jumbo > frames) can cause a node to get stuck in a permanent UJ status (as reflected > in nodetool). It's possible the node can stay in this way for an extended > period of time. Once the isolated node rejoins due to a network repair, it > can cause extensive data loss to the healthy nodes. > > If the node were completely isolated gc_grace_seconds would prevent the node > from joining after the specified period. Other corner cases besides "DN" > should be covered if applicable. > > Reference: > JTAC 2018-0303-0029 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14577) gc_grace_seconds should include UJ (Up/Joining) status period
John Knost created CASSANDRA-14577: -- Summary: gc_grace_seconds should include UJ (Up/Joining) status period Key: CASSANDRA-14577 URL: https://issues.apache.org/jira/browse/CASSANDRA-14577 Project: Cassandra Issue Type: Improvement Components: Coordination Environment: Issue observed in environment running Contrail 3.0.3.3-22/Cassandra 2.1.13 Reporter: John Knost Partial network connectivity (e.g. and MTU mismatch that blackholes jumbo frames) can cause a node to get stuck in a permanent UJ status (as reflected in nodetool). It's possible the node can stay in this way for an extended period of time. Once the isolated node rejoins due to a network repair, it can cause extensive data loss to the healthy nodes. If the node were completely isolated gc_grace_seconds would prevent the node from joining after the specified period. Other corner cases besides "DN" should be covered if applicable. Reference: JTAC 2018-0303-0029 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14459) DynamicEndpointSnitch should never prefer latent nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Lynch updated CASSANDRA-14459:
-
Status: Patch Available (was: In Progress)
> DynamicEndpointSnitch should never prefer latent nodes
> --
>
> Key: CASSANDRA-14459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14459
> Project: Cassandra
> Issue Type: Improvement
> Components: Coordination
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Minor
> Fix For: 4.x
>
>
> The DynamicEndpointSnitch has two unfortunate behaviors that allow it to
> provide latent hosts as replicas:
> # Loses all latency information when Cassandra restarts
> # Clears latency information entirely every ten minutes (by default),
> allowing global queries to be routed to _other datacenters_ (and local
> queries cross racks/azs)
> This means that the first few queries after restart/reset could be quite slow
> compared to average latencies. I propose we solve this by resetting to the
> minimum observed latency instead of completely clearing the samples and
> extending the {{isLatencyForSnitch}} idea to a three state variable instead
> of two, in particular {{YES}}, {{NO}}, {{MAYBE}}. This extension allows
> {{EchoMessages}} and {{PingMessages}} to send {{MAYBE}} indicating that the
> DS should use those measurements if it only has one or fewer samples for a
> host. This fixes both problems because on process restart we send out
> {{PingMessages}} / {{EchoMessages}} as part of startup, and we would reset to
> effectively the RTT of the hosts (also at that point normal gossip
> {{EchoMessages}} have an opportunity to add an additional latency
> measurement).
> This strategy also nicely deals with the "a host got slow but now it's fine"
> problem that the DS resets were (afaik) designed to stop because the
> {{EchoMessage}} ping latency will count only after the reset for that host.
> Ping latency is a more reasonable lower bound on host latency (as opposed to
> status quo of zero).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14575) Reevaluate when to drop an internode connection on message error
[ https://issues.apache.org/jira/browse/CASSANDRA-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-14575: Status: Patch Available (was: Open) > Reevaluate when to drop an internode connection on message error > > > Key: CASSANDRA-14575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14575 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Minor > Fix For: 4.0 > > > As mentioned in CASSANDRA-14574, explore if and when we can safely ignore an > incoming internode message on certain classes of failure. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14574) Incomplete handling of exceptions when decoding incoming messages
[
https://issues.apache.org/jira/browse/CASSANDRA-14574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Brown updated CASSANDRA-14574:
Status: Patch Available (was: Open)
> Incomplete handling of exceptions when decoding incoming messages
> --
>
> Key: CASSANDRA-14574
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14574
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Aleksey Yeschenko
>Assignee: Jason Brown
>Priority: Major
> Fix For: 4.0
>
>
> {{MessageInHandler.decode()}} occasionally reads the payload incorrectly,
> passing the full message to {{MessageIn.read()}} instead of just the payload
> bytes.
> You can see the stack trace in the logs from this [CI
> run|https://circleci.com/gh/iamaleksey/cassandra/437#tests/containers/38].
> {code}
> Caused by: java.lang.AssertionError: null
> at
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:351)
> at
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:371)
> at
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:335)
> at org.apache.cassandra.net.MessageIn.read(MessageIn.java:158)
> at
> org.apache.cassandra.net.async.MessageInHandler.decode(MessageInHandler.java:132)
> {code}
> Reconstructed, truncated stream passed to {{MessageIn.read()}}:
> {{000b000743414c5f42414301002a01e1a5c9b089fd11e8b517436ee124300704005d10fc50ec}}
> You can clearly see parameters in there encoded before the payload:
> {{[43414c5f424143 - CAL_BAC] [01 - ONE_BYTE] [002a - 42, payload size] 01 e1
> a5 c9 b0 89 fd 11 e8 b5 17 43 6e e1 24 30 07 04 00 00 00 1d 10 fc 50 ec}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14576) Improve logging in MessageInHandler's constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-14576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-14576: Fix Version/s: 4.0 > Improve logging in MessageInHandler's constructor > - > > Key: CASSANDRA-14576 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14576 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Trivial > Fix For: 4.0 > > > There's a minor logging bug in when when complaining about unacceptable > messaging version in MessageInHandler's constructor. The passed in version > does not get logged (even though it should). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14576) Improve logging in MessageInHandler's constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-14576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-14576: Status: Patch Available (was: Open) > Improve logging in MessageInHandler's constructor > - > > Key: CASSANDRA-14576 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14576 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Trivial > > There's a minor logging bug in when when complaining about unacceptable > messaging version in MessageInHandler's constructor. The passed in version > does not get logged (even though it should). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14576) Improve logging in MessageInHandler's constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-14576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551073#comment-16551073 ] Jason Brown commented on CASSANDRA-14576: - Trivial patch, with test! ||mih-ctor|| |[branch|https://github.com/jasobrown/cassandra/tree/mih-ctor]| |[utests dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/mih-ctor]| || > Improve logging in MessageInHandler's constructor > - > > Key: CASSANDRA-14576 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14576 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Trivial > > There's a minor logging bug in when when complaining about unacceptable > messaging version in MessageInHandler's constructor. The passed in version > does not get logged (even though it should). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14576) Improve logging in MessageInHandler's constructor
Jason Brown created CASSANDRA-14576: --- Summary: Improve logging in MessageInHandler's constructor Key: CASSANDRA-14576 URL: https://issues.apache.org/jira/browse/CASSANDRA-14576 Project: Cassandra Issue Type: Improvement Reporter: Jason Brown Assignee: Jason Brown There's a minor logging bug in when when complaining about unacceptable messaging version in MessageInHandler's constructor. The passed in version does not get logged (even though it should). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14459) DynamicEndpointSnitch should never prefer latent nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551064#comment-16551064
]
Joseph Lynch commented on CASSANDRA-14459:
--
Ok based on the feedback I've moved the latency probes into a scheduled
executor that runs every second and sends a single message to one node needing
latency probes. If no probes are needed then they are not sent. I've gone a
step further and posted a follow up commit which replaces all the uses of
histograms with a simpler (and 10x more performant) EMA implementation. The
second patch is very optional but I know that some folks have mentioned they
don't like all the garbage that the Histograms create so I fixed it.
||trunk||trunk+EMA||
|[patch|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-14459]|[patch|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-14459-EMA]|
|[unit
tests|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-14459#diff-f1baf62fd510947bf60e9a9def69810b]
[!https://circleci.com/gh/jolynch/cassandra/tree/CASSANDRA-14459.png?circle-token=
1102a59698d04899ec971dd36e925928f7b521f5!|https://circleci.com/gh/jolynch/cassandra/tree/CASSANDRA-14459]|[unit
tests|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-14459-EMA#diff-f1baf62fd510947bf60e9a9def69810b]
[microbenchmark|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-14459-EMA#diff-f48455469e3cd6a2e225e3cb2b389d93]
[!https://circleci.com/gh/jolynch/cassandra/tree/CASSANDRA-14459.png?circle-token=
1102a59698d04899ec971dd36e925928f7b521f5!|https://circleci.com/gh/jolynch/cassandra/tree/CASSANDRA-14459-EMA]|
> DynamicEndpointSnitch should never prefer latent nodes
> --
>
> Key: CASSANDRA-14459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14459
> Project: Cassandra
> Issue Type: Improvement
> Components: Coordination
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Minor
> Fix For: 4.x
>
>
> The DynamicEndpointSnitch has two unfortunate behaviors that allow it to
> provide latent hosts as replicas:
> # Loses all latency information when Cassandra restarts
> # Clears latency information entirely every ten minutes (by default),
> allowing global queries to be routed to _other datacenters_ (and local
> queries cross racks/azs)
> This means that the first few queries after restart/reset could be quite slow
> compared to average latencies. I propose we solve this by resetting to the
> minimum observed latency instead of completely clearing the samples and
> extending the {{isLatencyForSnitch}} idea to a three state variable instead
> of two, in particular {{YES}}, {{NO}}, {{MAYBE}}. This extension allows
> {{EchoMessages}} and {{PingMessages}} to send {{MAYBE}} indicating that the
> DS should use those measurements if it only has one or fewer samples for a
> host. This fixes both problems because on process restart we send out
> {{PingMessages}} / {{EchoMessages}} as part of startup, and we would reset to
> effectively the RTT of the hosts (also at that point normal gossip
> {{EchoMessages}} have an opportunity to add an additional latency
> measurement).
> This strategy also nicely deals with the "a host got slow but now it's fine"
> problem that the DS resets were (afaik) designed to stop because the
> {{EchoMessage}} ping latency will count only after the reset for that host.
> Ping latency is a more reasonable lower bound on host latency (as opposed to
> status quo of zero).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14575) Reevaluate when to drop an internode connection on message error
[
https://issues.apache.org/jira/browse/CASSANDRA-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551061#comment-16551061
]
Jason Brown commented on CASSANDRA-14575:
-
Patch available here:
||14575||
|[branch|https://github.com/jasobrown/cassandra/tree/14575]|
|[utests
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14575]|
||
Patch contains the following changes:
- catch the {{UnknownTableException}} in the body of the {{decode()}} method
itself, and if thrown advance the buf's readIndex to the end of the payload.
Added a test to confirm behavior.
- check for the unknown {{ParameterType}} (parameterType will be null). If
known, skip over the value's bytes. I could not write a test for this as
{{ParameterType}} is an enum, and all of the message deser code expects that
type (and you can't add to or derive from en existing enum).
> Reevaluate when to drop an internode connection on message error
>
>
> Key: CASSANDRA-14575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14575
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 4.0
>
>
> As mentioned in CASSANDRA-14574, explore if and when we can safely ignore an
> incoming internode message on certain classes of failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumanth Pasupuleti updated CASSANDRA-14557:
---
Attachment: 14557-trunk.txt
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Fix For: 4.0
>
> Attachments: 14557-trunk.txt
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumanth Pasupuleti updated CASSANDRA-14557:
---
Attachment: (was: 14557-trunk.txt)
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Fix For: 4.0
>
> Attachments: 14557-trunk.txt
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14289) Document sstable tools
[ https://issues.apache.org/jira/browse/CASSANDRA-14289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551004#comment-16551004 ] Valerie Parham-Thompson commented on CASSANDRA-14289: - PS I removed the "Usage" header in this sstable* generator script to avoid the issue [~hkroger] mentioned above causing the nodetool "Usage" header to show up in the page navigation. > Document sstable tools > -- > > Key: CASSANDRA-14289 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14289 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Hannu Kröger >Priority: Major > Attachments: gen-sstable-docs.py, sstabledocs.tar.gz > > > Following tools are missing in the documentation of cassandra tools on the > documentation site (http://cassandra.apache.org/doc/latest/tools/index.html): > * sstabledump > * sstableexpiredblockers > * sstablelevelreset > * sstableloader > * sstablemetadata > * sstableofflinerelevel > * sstablerepairedset > * sstablescrub > * sstablesplit > * sstableupgrade > * sstableutil > * sstableverify -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14289) Document sstable tools
[ https://issues.apache.org/jira/browse/CASSANDRA-14289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551003#comment-16551003 ] Valerie Parham-Thompson commented on CASSANDRA-14289: - I have attached the generation script and the generated .rst/.txt files to this ticket for reference as needed. I was using restview to look at the .rst files locally. I'm not sure about submitting a PR for this yet because the help files within the sstable* tools aren't consistent. Many are very brief, and three tools have no help files. I excluded those three from the script and noted this in the comments. This script works really well for nodetool tools, but I have doubts it will be useful for the sstable* docs. I wonder if it will be better to adjust the code of each sstable* tool to include more help text, or to do manual sstable* files for the docs/website. What do you think is best, [~hkroger], [~jjirsa]? > Document sstable tools > -- > > Key: CASSANDRA-14289 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14289 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Hannu Kröger >Priority: Major > Attachments: gen-sstable-docs.py, sstabledocs.tar.gz > > > Following tools are missing in the documentation of cassandra tools on the > documentation site (http://cassandra.apache.org/doc/latest/tools/index.html): > * sstabledump > * sstableexpiredblockers > * sstablelevelreset > * sstableloader > * sstablemetadata > * sstableofflinerelevel > * sstablerepairedset > * sstablescrub > * sstablesplit > * sstableupgrade > * sstableutil > * sstableverify -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14289) Document sstable tools
[ https://issues.apache.org/jira/browse/CASSANDRA-14289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valerie Parham-Thompson updated CASSANDRA-14289: Attachment: sstabledocs.tar.gz > Document sstable tools > -- > > Key: CASSANDRA-14289 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14289 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Hannu Kröger >Priority: Major > Attachments: gen-sstable-docs.py, sstabledocs.tar.gz > > > Following tools are missing in the documentation of cassandra tools on the > documentation site (http://cassandra.apache.org/doc/latest/tools/index.html): > * sstabledump > * sstableexpiredblockers > * sstablelevelreset > * sstableloader > * sstablemetadata > * sstableofflinerelevel > * sstablerepairedset > * sstablescrub > * sstablesplit > * sstableupgrade > * sstableutil > * sstableverify -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14289) Document sstable tools
[ https://issues.apache.org/jira/browse/CASSANDRA-14289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valerie Parham-Thompson updated CASSANDRA-14289: Attachment: gen-sstable-docs.py > Document sstable tools > -- > > Key: CASSANDRA-14289 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14289 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Hannu Kröger >Priority: Major > Attachments: gen-sstable-docs.py, sstabledocs.tar.gz > > > Following tools are missing in the documentation of cassandra tools on the > documentation site (http://cassandra.apache.org/doc/latest/tools/index.html): > * sstabledump > * sstableexpiredblockers > * sstablelevelreset > * sstableloader > * sstablemetadata > * sstableofflinerelevel > * sstablerepairedset > * sstablescrub > * sstablesplit > * sstableupgrade > * sstableutil > * sstableverify -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14575) Reevaluate when to drop an internode connection on message error
[
https://issues.apache.org/jira/browse/CASSANDRA-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550973#comment-16550973
]
Jason Brown commented on CASSANDRA-14575:
-
ftr, CASSANDRA-5725 introduced special casing the {{UnknownTableException}} (at
that time it was still {{UnknownColumnFamilyException}}). Before that ticket,
the exception was being thrown and just caught in a generic catch clause (still
closing the connection). CASSANDRA-5725 just special cased the exception for
logging purposes.
> Reevaluate when to drop an internode connection on message error
>
>
> Key: CASSANDRA-14575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14575
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 4.0
>
>
> As mentioned in CASSANDRA-14574, explore if and when we can safely ignore an
> incoming internode message on certain classes of failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-10023: -- Reviewer: (was: sankalp kohli) > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: Damien Stevenson >Priority: Minor > Labels: lhf > Fix For: 4.x > > Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, > CASSANDRA-10023.patch > > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14575) Reevaluate when to drop an internode connection on message error
[
https://issues.apache.org/jira/browse/CASSANDRA-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550730#comment-16550730
]
Jason Brown edited comment on CASSANDRA-14575 at 7/20/18 12:47 PM:
---
[~iamaleksey] mentioned this in CASSANDRA-14574
{quote}As for when it's safe to ignore a failed to deser message - at least in
the case of unknown table id it is, and that's a common enough scenario. Think
someone creates a table and starts writes before waiting for schema to
propagate. Or batchlog replays a mutation to a node on which a table is either
not yet known, or has been dropped since. Or, occasionally, when we add new
tables and use them during mixed mode/upgrade period.
{quote}
Yup, at a minimum I think we can handle this one here, as we already know the
payload length, and it's easy to skip beyond this message. Possibly all payload
deser failures are ok are to ignore, as long as we can skip the payload bytes.
If, however, we fail in parsing any other part of the message (magic, params,
and so on), we're pretty much screwed and will need to shut down the connection.
ftr, in CASSANDRA-14447, if we receive a verb id we do not recognize, we'll
still deserialize the message ([payload is
skipped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageIn.java#L150],
as we have no serializer for the verb id we don't know), and the message [will
be
dropped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageDeliveryTask.java#L66]
in {{MessageDeliveryTask.process()}}. Thus, we don't need to worry about
unknown verbs for this ticket.
Reagrding params out of the message, with CASSANDRA-7544, we introduced an enum
for all parameter names, {{ParameterType}}. In
{{MessageInHandler.readParams()}}, we [look up the
{{ParameterType}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/MessageInHandler.java#L160]
based on the string we read from the stream. If the string is unknown (it came
from a future version), the lookup returns null. -Several lines later we'll try
to insert that null key into the {{EnumMap}}, and we'll get an exception and
end up closing the connection. It's simple enough to still deserialize the key
and value, and just not insert into the map if the key is null (effectively
ignoring the param). This should be handled by this ticket, as well.-
-CORRECTION: we need to know the {{parameterType}} to deserialize the value.
Thus we have to fail the connection as we won't know the length of the value to
read from the buf-.
Ughh, I need more coffee. CORRECTION 2: We *do* know the length of the value to
read, we just won't know how to deserialize it. Thus, we can just skip the
deser and inserting into the map step (skipping the value's bytes), and retain
the connection as we'll still be in a deterministic state of the byte stream.
was (Author: jasobrown):
[~iamaleksey] mentioned this in CASSANDRA-14574
{quote}As for when it's safe to ignore a failed to deser message - at least in
the case of unknown table id it is, and that's a common enough scenario. Think
someone creates a table and starts writes before waiting for schema to
propagate. Or batchlog replays a mutation to a node on which a table is either
not yet known, or has been dropped since. Or, occasionally, when we add new
tables and use them during mixed mode/upgrade period.
{quote}
Yup, at a minimum I think we can handle this one here, as we already know the
payload length, and it's easy to skip beyond this message. Possibly all payload
deser failures are ok are to ignore, as long as we can skip the payload bytes.
If, however, we fail in parsing any other part of the message (magic, params,
and so on), we're pretty much screwed and will need to shut down the connection.
ftr, in CASSANDRA-14447, if we receive a verb id we do not recognize, we'll
still deserialize the message ([payload is
skipped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageIn.java#L150],
as we have no serializer for the verb id we don't know), and the message [will
be
dropped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageDeliveryTask.java#L66]
in {{MessageDeliveryTask.process()}}. Thus, we don't need to worry about
unknown verbs for this ticket.
Reagrding params out of the message, with CASSANDRA-7544, we introduced an enum
for all parameter names, {{ParameterType}}. In
{{MessageInHandler.readParams()}}, we [look up the
{{ParameterType}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/MessageInHandler.java#L160]
based on the string we read from the stream. If the string is unknown (it came
from a future version), the lookup returns null. -Several lines later we'll try
to insert that null key into the
[jira] [Comment Edited] (CASSANDRA-14575) Reevaluate when to drop an internode connection on message error
[
https://issues.apache.org/jira/browse/CASSANDRA-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550730#comment-16550730
]
Jason Brown edited comment on CASSANDRA-14575 at 7/20/18 12:44 PM:
---
[~iamaleksey] mentioned this in CASSANDRA-14574
{quote}As for when it's safe to ignore a failed to deser message - at least in
the case of unknown table id it is, and that's a common enough scenario. Think
someone creates a table and starts writes before waiting for schema to
propagate. Or batchlog replays a mutation to a node on which a table is either
not yet known, or has been dropped since. Or, occasionally, when we add new
tables and use them during mixed mode/upgrade period.
{quote}
Yup, at a minimum I think we can handle this one here, as we already know the
payload length, and it's easy to skip beyond this message. Possibly all payload
deser failures are ok are to ignore, as long as we can skip the payload bytes.
If, however, we fail in parsing any other part of the message (magic, params,
and so on), we're pretty much screwed and will need to shut down the connection.
ftr, in CASSANDRA-14447, if we receive a verb id we do not recognize, we'll
still deserialize the message ([payload is
skipped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageIn.java#L150],
as we have no serializer for the verb id we don't know), and the message [will
be
dropped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageDeliveryTask.java#L66]
in {{MessageDeliveryTask.process()}}. Thus, we don't need to worry about
unknown verbs for this ticket.
Reagrding params out of the message, with CASSANDRA-7544, we introduced an enum
for all parameter names, {{ParameterType}}. In
{{MessageInHandler.readParams()}}, we [look up the
{{ParameterType}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/MessageInHandler.java#L160]
based on the string we read from the stream. If the string is unknown (it came
from a future version), the lookup returns null. -Several lines later we'll try
to insert that null key into the {{EnumMap}}, and we'll get an exception and
end up closing the connection. It's simple enough to still deserialize the key
and value, and just not insert into the map if the key is null (effectively
ignoring the param). This should be handled by this ticket, as well.-
-CORRECTION: we need to know the {{parameterType}} to deserialize the value.
Thus we have to fail the connection as we won't know the length of the value to
read from the buf-.
Ughh, I need more coffee. CORRECTION 2: We *do* know the length of the value to
read, we just won't know how to deserialize it. Thus, we can just the deser and
inserting into the map step, and retain the connection as we'll still be in a
deterministic state of the byte stream.
was (Author: jasobrown):
[~iamaleksey] mentioned this in CASSANDRA-14574
{quote}As for when it's safe to ignore a failed to deser message - at least in
the case of unknown table id it is, and that's a common enough scenario. Think
someone creates a table and starts writes before waiting for schema to
propagate. Or batchlog replays a mutation to a node on which a table is either
not yet known, or has been dropped since. Or, occasionally, when we add new
tables and use them during mixed mode/upgrade period.
{quote}
Yup, at a minimum I think we can handle this one here, as we already know the
payload length, and it's easy to skip beyond this message. Possibly all payload
deser failures are ok are to ignore, as long as we can skip the payload bytes.
If, however, we fail in parsing any other part of the message (magic, params,
and so on), we're pretty much screwed and will need to shut down the connection.
ftr, in CASSANDRA-14447, if we receive a verb id we do not recognize, we'll
still deserialize the message ([payload is
skipped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageIn.java#L150],
as we have no serializer for the verb id we don't know), and the message [will
be
dropped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageDeliveryTask.java#L66]
in {{MessageDeliveryTask.process()}}. Thus, we don't need to worry about
unknown verbs for this ticket.
Reagrding params out of the message, with CASSANDRA-7544, we introduced an enum
for all parameter names, {{ParameterType}}. In
{{MessageInHandler.readParams()}}, we [look up the
{{ParameterType}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/MessageInHandler.java#L160]
based on the string we read from the stream. If the string is unknown (it came
from a future version), the lookup returns null. -Several lines later we'll try
to insert that null key into the {{EnumMap}}, and we'll get an
[jira] [Comment Edited] (CASSANDRA-14575) Reevaluate when to drop an internode connection on message error
[
https://issues.apache.org/jira/browse/CASSANDRA-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550730#comment-16550730
]
Jason Brown edited comment on CASSANDRA-14575 at 7/20/18 12:43 PM:
---
[~iamaleksey] mentioned this in CASSANDRA-14574
{quote}As for when it's safe to ignore a failed to deser message - at least in
the case of unknown table id it is, and that's a common enough scenario. Think
someone creates a table and starts writes before waiting for schema to
propagate. Or batchlog replays a mutation to a node on which a table is either
not yet known, or has been dropped since. Or, occasionally, when we add new
tables and use them during mixed mode/upgrade period.
{quote}
Yup, at a minimum I think we can handle this one here, as we already know the
payload length, and it's easy to skip beyond this message. Possibly all payload
deser failures are ok are to ignore, as long as we can skip the payload bytes.
If, however, we fail in parsing any other part of the message (magic, params,
and so on), we're pretty much screwed and will need to shut down the connection.
ftr, in CASSANDRA-14447, if we receive a verb id we do not recognize, we'll
still deserialize the message ([payload is
skipped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageIn.java#L150],
as we have no serializer for the verb id we don't know), and the message [will
be
dropped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageDeliveryTask.java#L66]
in {{MessageDeliveryTask.process()}}. Thus, we don't need to worry about
unknown verbs for this ticket.
Reagrding params out of the message, with CASSANDRA-7544, we introduced an enum
for all parameter names, {{ParameterType}}. In
{{MessageInHandler.readParams()}}, we [look up the
{{ParameterType}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/MessageInHandler.java#L160]
based on the string we read from the stream. If the string is unknown (it came
from a future version), the lookup returns null. -Several lines later we'll try
to insert that null key into the {{EnumMap}}, and we'll get an exception and
end up closing the connection. It's simple enough to still deserialize the key
and value, and just not insert into the map if the key is null (effectively
ignoring the param). This should be handled by this ticket, as well.-
-CORRECTION: we need to know the {{parameterType}} to deserialize the value.
Thus we have to fail the connection as we won't know the length of the value to
read from the buf.\-
Ughh, I need more coffee. CORRECTION 2: We *do* know the length of the value to
read, we just won't know how to deserialize it. Thus, we can just the deser and
inserting into the map step, and retain the connection as we'll still be in a
deterministic state of the byte stream.
was (Author: jasobrown):
[~iamaleksey] mentioned this in CASSANDRA-14574
{quote}As for when it's safe to ignore a failed to deser message - at least in
the case of unknown table id it is, and that's a common enough scenario. Think
someone creates a table and starts writes before waiting for schema to
propagate. Or batchlog replays a mutation to a node on which a table is either
not yet known, or has been dropped since. Or, occasionally, when we add new
tables and use them during mixed mode/upgrade period.
{quote}
Yup, at a minimum I think we can handle this one here, as we already know the
payload length, and it's easy to skip beyond this message. Possibly all payload
deser failures are ok are to ignore, as long as we can skip the payload bytes.
If, however, we fail in parsing any other part of the message (magic, params,
and so on), we're pretty much screwed and will need to shut down the connection.
ftr, in CASSANDRA-14447, if we receive a verb id we do not recognize, we'll
still deserialize the message ([payload is
skipped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageIn.java#L150],
as we have no serializer for the verb id we don't know), and the message [will
be
dropped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageDeliveryTask.java#L66]
in {{MessageDeliveryTask.process()}}. Thus, we don't need to worry about
unknown verbs for this ticket.
Reagrding params out of the message, with CASSANDRA-7544, we introduced an enum
for all parameter names, {{ParameterType}}. In
{{MessageInHandler.readParams()}}, we [look up the
{{ParameterType}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/MessageInHandler.java#L160]
based on the string we read from the stream. If the string is unknown (it came
from a future version), the lookup returns null. -Several lines later we'll try
to insert that null key into the {{EnumMap}}, and we'll get an
[jira] [Comment Edited] (CASSANDRA-14575) Reevaluate when to drop an internode connection on message error
[
https://issues.apache.org/jira/browse/CASSANDRA-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550730#comment-16550730
]
Jason Brown edited comment on CASSANDRA-14575 at 7/20/18 12:39 PM:
---
[~iamaleksey] mentioned this in CASSANDRA-14574
{quote}As for when it's safe to ignore a failed to deser message - at least in
the case of unknown table id it is, and that's a common enough scenario. Think
someone creates a table and starts writes before waiting for schema to
propagate. Or batchlog replays a mutation to a node on which a table is either
not yet known, or has been dropped since. Or, occasionally, when we add new
tables and use them during mixed mode/upgrade period.
{quote}
Yup, at a minimum I think we can handle this one here, as we already know the
payload length, and it's easy to skip beyond this message. Possibly all payload
deser failures are ok are to ignore, as long as we can skip the payload bytes.
If, however, we fail in parsing any other part of the message (magic, params,
and so on), we're pretty much screwed and will need to shut down the connection.
ftr, in CASSANDRA-14447, if we receive a verb id we do not recognize, we'll
still deserialize the message ([payload is
skipped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageIn.java#L150],
as we have no serializer for the verb id we don't know), and the message [will
be
dropped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageDeliveryTask.java#L66]
in {{MessageDeliveryTask.process()}}. Thus, we don't need to worry about
unknown verbs for this ticket.
Reagrding params out of the message, with CASSANDRA-7544, we introduced an enum
for all parameter names, {{ParameterType}}. In
{{MessageInHandler.readParams()}}, we [look up the
{{ParameterType}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/MessageInHandler.java#L160]
based on the string we read from the stream. If the string is unknown (it came
from a future version), the lookup returns null. -Several lines later we'll try
to insert that null key into the {{EnumMap}}, and we'll get an exception and
end up closing the connection. It's simple enough to still deserialize the key
and value, and just not insert into the map if the key is null (effectively
ignoring the param). This should be handled by this ticket, as well.-
CORRECTION: we need to know the {{parameterType}} to deserialize the value.
Thus we have to fail the connection as we won't know the length of the value to
read from the buf.
was (Author: jasobrown):
[~iamaleksey] mentioned this in CASSANDRA-14574
{quote}As for when it's safe to ignore a failed to deser message - at least in
the case of unknown table id it is, and that's a common enough scenario. Think
someone creates a table and starts writes before waiting for schema to
propagate. Or batchlog replays a mutation to a node on which a table is either
not yet known, or has been dropped since. Or, occasionally, when we add new
tables and use them during mixed mode/upgrade period.
{quote}
Yup, at a minimum I think we can handle this one here, as we already know the
payload length, and it's easy to skip beyond this message. Possibly all payload
deser failures are ok are to ignore, as long as we can skip the payload bytes.
If, however, we fail in parsing any other part of the message (magic, params,
and so on), we're pretty much screwed and will need to shut down the connection.
ftr, in CASSANDRA-14447, if we receive a verb id we do not recognize, we'll
still deserialize the message ([payload is
skipped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageIn.java#L150],
as we have no serializer for the verb id we don't know), and the message [will
be
dropped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageDeliveryTask.java#L66]
in {{MessageDeliveryTask.process()}}. Thus, we don't need to worry about
unknown verbs for this ticket.
Reagrding params out of the message, with CASSANDRA-7544, we introduced an enum
for all parameter names, {{ParameterType}}. In
{{MessageInHandler.readParams()}}, we [look up the
{{ParameterType}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/MessageInHandler.java#L160]
based on the string we read from the stream. If the string is unknown (it came
from a future version), the lookup returns null. Several lines later we'll try
to insert that null key into the {{EnumMap}}, and we'll get an exception and
end up closing the connection. It's simple enough to still deserialize the key
and value, and just not insert into the map if the key is null (effectively
ignoring the param). This should be handled by this ticket, as well.
> Reevaluate when to drop an internode
[jira] [Comment Edited] (CASSANDRA-14575) Reevaluate when to drop an internode connection on message error
[
https://issues.apache.org/jira/browse/CASSANDRA-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550730#comment-16550730
]
Jason Brown edited comment on CASSANDRA-14575 at 7/20/18 12:33 PM:
---
[~iamaleksey] mentioned this in CASSANDRA-14574
{quote}As for when it's safe to ignore a failed to deser message - at least in
the case of unknown table id it is, and that's a common enough scenario. Think
someone creates a table and starts writes before waiting for schema to
propagate. Or batchlog replays a mutation to a node on which a table is either
not yet known, or has been dropped since. Or, occasionally, when we add new
tables and use them during mixed mode/upgrade period.
{quote}
Yup, at a minimum I think we can handle this one here, as we already know the
payload length, and it's easy to skip beyond this message. Possibly all payload
deser failures are ok are to ignore, as long as we can skip the payload bytes.
If, however, we fail in parsing any other part of the message (magic, params,
and so on), we're pretty much screwed and will need to shut down the connection.
ftr, in CASSANDRA-14447, if we receive a verb id we do not recognize, we'll
still deserialize the message ([payload is
skipped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageIn.java#L150],
as we have no serializer for the verb id we don't know), and the message [will
be
dropped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageDeliveryTask.java#L66]
in {{MessageDeliveryTask.process()}}. Thus, we don't need to worry about
unknown verbs for this ticket.
Reagrding params out of the message, with CASSANDRA-7544, we introduced an enum
for all parameter names, {{ParameterType}}. In
{{MessageInHandler.readParams()}}, we [look up the
{{ParameterType}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/MessageInHandler.java#L160]
based on the string we read from the stream. If the string is unknown (it came
from a future version), the lookup returns null. Several lines later we'll try
to insert that null key into the {{EnumMap}}, and we'll get an exception and
end up closing the connection. It's simple enough to still deserialize the key
and value, and just not insert into the map if the key is null (effectively
ignoring the param). This should be handled by this ticket, as well.
was (Author: jasobrown):
[~iamaleksey] mentioned this in CASSANDRA-14574
{quote}As for when it's safe to ignore a failed to deser message - at least in
the case of unknown table id it is, and that's a common enough scenario. Think
someone creates a table and starts writes before waiting for schema to
propagate. Or batchlog replays a mutation to a node on which a table is either
not yet known, or has been dropped since. Or, occasionally, when we add new
tables and use them during mixed mode/upgrade period.
{quote}
Yup, at a minimum I think we can handle this one here, as we already know the
payload length, and it's easy to skip beyond this message. Possibly all payload
deser failures are ok are to ignore, as long as we can skip the payload bytes.
If, however, we fail in parsing any other part of the message (magic, params,
and so on), we're pretty much screwed and will need to shut down the connection.
ftr, in CASSANDRA-14447, if we receive a verb id we do not recognize, we'll
still deserialize the message ([payload is
skipped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageIn.java#L150],
as we have no serializer for the verb id we don't know), and the message [will
be
dropped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageDeliveryTask.java#L66]
in {{MessageDeliveryTask.process()}}. Thus, we don't need to worry about
unknown verbs for this ticket.
Reagrding params out of the message, with CASANDRA-7544, we introduced an enum
for all parameter names, {{ParameterType}}. In
{{MessageInHandler.readParams()}}, we [look up the
{{ParameterType}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/MessageInHandler.java#L160]
based on the string we read from the stream. If the string is unknown (it came
from a future version), the lookup returns null. Several lines later we'll try
to insert that null key into the {{EnumMap}}, and we'll get an exception and
end up closing the connection. It's simple enough to still deserialize the key
and value, and just not insert into the map if the key is null (effectively
ignoring the param). This should be handled by this ticket, as well.
> Reevaluate when to drop an internode connection on message error
>
>
> Key: CASSANDRA-14575
> URL:
[jira] [Commented] (CASSANDRA-14575) Reevaluate when to drop an internode connection on message error
[
https://issues.apache.org/jira/browse/CASSANDRA-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550730#comment-16550730
]
Jason Brown commented on CASSANDRA-14575:
-
[~iamaleksey] mentioned this in CASSANDRA-14574
{quote}As for when it's safe to ignore a failed to deser message - at least in
the case of unknown table id it is, and that's a common enough scenario. Think
someone creates a table and starts writes before waiting for schema to
propagate. Or batchlog replays a mutation to a node on which a table is either
not yet known, or has been dropped since. Or, occasionally, when we add new
tables and use them during mixed mode/upgrade period.
{quote}
Yup, at a minimum I think we can handle this one here, as we already know the
payload length, and it's easy to skip beyond this message. Possibly all payload
deser failures are ok are to ignore, as long as we can skip the payload bytes.
If, however, we fail in parsing any other part of the message (magic, params,
and so on), we're pretty much screwed and will need to shut down the connection.
ftr, in CASSANDRA-14447, if we receive a verb id we do not recognize, we'll
still deserialize the message ([payload is
skipped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageIn.java#L150],
as we have no serializer for the verb id we don't know), and the message [will
be
dropped|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessageDeliveryTask.java#L66]
in {{MessageDeliveryTask.process()}}. Thus, we don't need to worry about
unknown verbs for this ticket.
Reagrding params out of the message, with CASANDRA-7544, we introduced an enum
for all parameter names, {{ParameterType}}. In
{{MessageInHandler.readParams()}}, we [look up the
{{ParameterType}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/MessageInHandler.java#L160]
based on the string we read from the stream. If the string is unknown (it came
from a future version), the lookup returns null. Several lines later we'll try
to insert that null key into the {{EnumMap}}, and we'll get an exception and
end up closing the connection. It's simple enough to still deserialize the key
and value, and just not insert into the map if the key is null (effectively
ignoring the param). This should be handled by this ticket, as well.
> Reevaluate when to drop an internode connection on message error
>
>
> Key: CASSANDRA-14575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14575
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 4.0
>
>
> As mentioned in CASSANDRA-14574, explore if and when we can safely ignore an
> incoming internode message on certain classes of failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14574) Incomplete handling of exceptions when decoding incoming messages
[
https://issues.apache.org/jira/browse/CASSANDRA-14574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550634#comment-16550634
]
Aleksey Yeschenko commented on CASSANDRA-14574:
---
bq. I agree, especially after seeing that we drop the connection when we get a
message for a table we don't know about yet. (I'll have to spelunk the git log
to uncover the original logic for that one).
That would be CASSANDRA-14168. As for when it's safe to ignore a failed to
deser message - at least in the case of unknown table id it is, and that's a
common enough scenario. Think someone creates a table and starts writes before
waiting for schema to propagate. Or batchlog replays a mutation to a node on
which a table is either not yet known, or has been dropped since. Or,
occasionally, when we add new tables and use them during mixed mode/upgrade
period. I'm pretty sure there is a JIRA somewhere, by Tyler, to address just
this, but we never quite came around to it.
> Incomplete handling of exceptions when decoding incoming messages
> --
>
> Key: CASSANDRA-14574
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14574
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Aleksey Yeschenko
>Assignee: Jason Brown
>Priority: Major
> Fix For: 4.0
>
>
> {{MessageInHandler.decode()}} occasionally reads the payload incorrectly,
> passing the full message to {{MessageIn.read()}} instead of just the payload
> bytes.
> You can see the stack trace in the logs from this [CI
> run|https://circleci.com/gh/iamaleksey/cassandra/437#tests/containers/38].
> {code}
> Caused by: java.lang.AssertionError: null
> at
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:351)
> at
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:371)
> at
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:335)
> at org.apache.cassandra.net.MessageIn.read(MessageIn.java:158)
> at
> org.apache.cassandra.net.async.MessageInHandler.decode(MessageInHandler.java:132)
> {code}
> Reconstructed, truncated stream passed to {{MessageIn.read()}}:
> {{000b000743414c5f42414301002a01e1a5c9b089fd11e8b517436ee124300704005d10fc50ec}}
> You can clearly see parameters in there encoded before the payload:
> {{[43414c5f424143 - CAL_BAC] [01 - ONE_BYTE] [002a - 42, payload size] 01 e1
> a5 c9 b0 89 fd 11 e8 b5 17 43 6e e1 24 30 07 04 00 00 00 1d 10 fc 50 ec}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14571) Fix race condition in MV build/propagate when there is existing data in the base table
[
https://issues.apache.org/jira/browse/CASSANDRA-14571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-14571:
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
LGTM, committed to trunk in {{13150b001a8ddf82a77ac9525c446b7e9e32325c}}
> Fix race condition in MV build/propagate when there is existing data in the
> base table
> --
>
> Key: CASSANDRA-14571
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14571
> Project: Cassandra
> Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0
>
>
> CASSANDRA-13426 exposed a race in MV initialisation and building, which now
> breaks, consistently,
> {{materialized_views_test.py::TestMaterializedViews::test_populate_mv_after_insert_wide_rows}}.
> CASSANDRA-14168 is also directly related.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14571) Fix race condition in MV build/propagate when there is existing data in the base table
[
https://issues.apache.org/jira/browse/CASSANDRA-14571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-14571:
Status: Ready to Commit (was: Patch Available)
> Fix race condition in MV build/propagate when there is existing data in the
> base table
> --
>
> Key: CASSANDRA-14571
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14571
> Project: Cassandra
> Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0
>
>
> CASSANDRA-13426 exposed a race in MV initialisation and building, which now
> breaks, consistently,
> {{materialized_views_test.py::TestMaterializedViews::test_populate_mv_after_insert_wide_rows}}.
> CASSANDRA-14168 is also directly related.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
cassandra git commit: Wait for schema agreement prior to building MVs
Repository: cassandra
Updated Branches:
refs/heads/trunk 8bc2fba3e -> 13150b001
Wait for schema agreement prior to building MVs
patch by Aleksey Yeschenko; reviewed by Sam Tunnicliffe for CASSANDRA-14571
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/13150b00
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/13150b00
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/13150b00
Branch: refs/heads/trunk
Commit: 13150b001a8ddf82a77ac9525c446b7e9e32325c
Parents: 8bc2fba
Author: Aleksey Yeshchenko
Authored: Wed Jul 18 22:55:23 2018 +0100
Committer: Sam Tunnicliffe
Committed: Fri Jul 20 09:52:51 2018 +0100
--
CHANGES.txt | 1 +
.../cassandra/db/view/ViewBuilderTask.java | 11 +
src/java/org/apache/cassandra/gms/Gossiper.java | 47
3 files changed, 59 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/13150b00/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 63831d7..fe4087b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0
+ * Wait for schema agreement prior to building MVs (CASSANDRA-14571)
* Make all DDL statements idempotent and not dependent on global state
(CASSANDRA-13426)
* Bump the hints messaging version to match the current one (CASSANDRA-14536)
* OffsetAwareConfigurationLoader doesn't set ssl storage port causing bind
errors in CircleCI (CASSANDRA-14546)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/13150b00/src/java/org/apache/cassandra/db/view/ViewBuilderTask.java
--
diff --git a/src/java/org/apache/cassandra/db/view/ViewBuilderTask.java
b/src/java/org/apache/cassandra/db/view/ViewBuilderTask.java
index 1b16f18..453cb62 100644
--- a/src/java/org/apache/cassandra/db/view/ViewBuilderTask.java
+++ b/src/java/org/apache/cassandra/db/view/ViewBuilderTask.java
@@ -23,6 +23,7 @@ import java.util.Collections;
import java.util.Iterator;
import java.util.UUID;
import java.util.concurrent.Callable;
+import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;
import com.google.common.base.Function;
@@ -52,6 +53,7 @@ import org.apache.cassandra.db.rows.UnfilteredRowIterator;
import org.apache.cassandra.db.rows.UnfilteredRowIterators;
import org.apache.cassandra.dht.Range;
import org.apache.cassandra.dht.Token;
+import org.apache.cassandra.gms.Gossiper;
import org.apache.cassandra.io.sstable.ReducingKeyIterator;
import org.apache.cassandra.io.sstable.format.SSTableReader;
import org.apache.cassandra.service.StorageProxy;
@@ -122,6 +124,15 @@ public class ViewBuilderTask extends CompactionInfo.Holder
implements Callable this.isStopped);
+if (!schemaConverged)
+logger.warn("Failed to get schema to converge before building view
{}.{}", baseCfs.keyspace.getName(), view.name);
+
Function> function;
function =
org.apache.cassandra.db.lifecycle.View.select(SSTableSet.CANONICAL, s ->
range.intersects(s.getBounds()));
http://git-wip-us.apache.org/repos/asf/cassandra/blob/13150b00/src/java/org/apache/cassandra/gms/Gossiper.java
--
diff --git a/src/java/org/apache/cassandra/gms/Gossiper.java
b/src/java/org/apache/cassandra/gms/Gossiper.java
index 3975187..7bb2583 100644
--- a/src/java/org/apache/cassandra/gms/Gossiper.java
+++ b/src/java/org/apache/cassandra/gms/Gossiper.java
@@ -23,6 +23,7 @@ import java.util.*;
import java.util.Map.Entry;
import java.util.concurrent.*;
import java.util.concurrent.locks.ReentrantLock;
+import java.util.function.BooleanSupplier;
import java.util.stream.Collectors;
import javax.annotation.Nullable;
@@ -1833,4 +1834,50 @@ public class Gossiper implements
IFailureDetectionEventListener, GossiperMBean
logger.info("No gossip backlog; proceeding");
}
+/**
+ * Blockingly wait for all live nodes to agree on the current schema
version.
+ *
+ * @param maxWait maximum time to wait for schema agreement
+ * @param unit TimeUnit of maxWait
+ * @return true if agreement was reached, false if not
+ */
+public boolean waitForSchemaAgreement(long maxWait, TimeUnit unit,
BooleanSupplier abortCondition)
+{
+int waited = 0;
+int toWait = 50;
+
+Set members = getLiveTokenOwners();
+
+while (true)
+{
+if (nodesAgreeOnSchema(members))
+return true;
+
+if (waited >= unit.toMillis(maxWait) ||
abortCondition.getAsBoolean())
+return false;
+
+Uninterruptibles.sleepUninterruptibly(toWait,
