You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benedict (JIRA)" <ji...@apache.org> on 2019/07/06 10:35:00 UTC
[jira] [Commented] (CASSANDRA-14779) Changing EndpointSnitch via
JMX has problems
[ https://issues.apache.org/jira/browse/CASSANDRA-14779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16879642#comment-16879642 ]
Benedict commented on CASSANDRA-14779:
--------------------------------------
[~icleasby], sorry again for atrociously dropping the ball on this.
Looking at the provided code, it looks like a strict improvement to me, but it would be better if we checked that all racks and DCs remain the same for all nodes, since any change would corrupt the ring. Does that sound reasonable to you?
It might even be sensible to introduce an abstract method to {{IEndpointSnitch}} that corroborates the ring remains unchanged, something like {{isRingEquivalent}}? That way we can quickly reject a change of class, and delegate each implementation to simply confirming the relevant information is the same.
> Changing EndpointSnitch via JMX has problems
> --------------------------------------------
>
> Key: CASSANDRA-14779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14779
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership, Observability/JMX
> Reporter: Benedict
> Assignee: Ian Cleasby
> Priority: Low
> Fix For: 4.x
>
>
> The snitch can be set via StorageService over JMX, for what reason I’m unsure. If this were to happen, we might encounter the following problems:
> * If the effective local DC were to change, we would not update it. Perhaps changing the local DC of a node should be rejected and cause it to fail, but presently, it would simply result in our disagreeing with the snitch.
> * During the transition, routing of queries might be broken, as we fetch the snitch multiple times in different locations when deciding where to route our query and writes. It’s not clear what the outcome of a discordant view of the ring would be.
> Probably, changing this information in a live cluster is dangerous and we should actually reject any effective changes to rack, or DC for any node. But presently we don’t seem to corroborate that this information remains the same. We don’t seem to perform any cluster wide confirmation that this data is consistent, generally, which perhaps we should also consider.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org