[
https://issues.apache.org/jira/browse/CASSANDRA-14190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16341466#comment-16341466
]
Samuel Fink commented on CASSANDRA-14190:
-----------------------------------------
[~jjirsa] I did a bit of testing with seed providers that throw unexpected
errors and it doesn't seem to cause any real problems. When running the
nodetool reloadseeds with a seed provider that throws an error the exception is
sent up to the nodetool output and the Cassandra instance continues running.
Because of the ordering of the operations that modify the in-memory list any
unexpected interruptions in the function leave the seed list in a consistent
and safe state.
That said, I wouldn't be opposed to adding a try/catch around the getSeeds call
if you have a suggestion of what exceptions to catch.
> Non-disruptive seed node list reload
> ------------------------------------
>
> Key: CASSANDRA-14190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14190
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration, Lifecycle
> Reporter: Samuel Fink
> Assignee: Samuel Fink
> Priority: Minor
> Fix For: 4.x
>
> Attachments: 14190-trunk.patch, 14190-trunk.patch
>
>
> Add a mechanism for reloading the Gossiper in-memory seed node IP list
> without requiring a service restart.
> The Gossiper keeps an in-memory copy of the seed node IP list and uses it
> during a gossip round to determine if the random node that was gossiped to is
> a seed node and for picking a seed node to gossip to in maybeGossipToSeed.
> Currently the Gossiper seed node list is only updated when an endpoint is
> removed, at the start of a shadow round, and on startup. Those scenarios
> don’t handle the case of seed nodes changing IP addresses (eg. DHCP lease
> changes) or additional seed nodes being added to the cluster.
> As described in CASSANDRA-3829 the current way to ensure that all nodes in
> the cluster have the same seed node list when there has been a change is to
> do a rolling restart of every node in the cluster. In large clusters rolling
> restarts can be very complicated to manage and can have performance impacts
> because the caches get flushed.
--
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
