[
https://issues.apache.org/jira/browse/CASSANDRA-10134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253719#comment-15253719
]
Sam Tunnicliffe commented on CASSANDRA-10134:
---------------------------------------------
Thanks [~jkni]
On reflection, the concern about MV builds when operators stop gossip is a fair
one. Reviewing SS, it seems to me that {{isInitialized}} is poorly named and
only really used to check the status of gossip, so I've renamed it to
{{gossipActive}} and only set it when gossip is actually started, rather than
on entry of {{initServer}}. With that renaming, I've re-purposed
{{isInitialized}} to indicate that {{initServer}} has completed and while I was
at it, renamed {{isSetupCompleted}} to {{isDaemonSetupCompleted}}, which I
think is more accurate. With those changes, MV builds will not be submitted
before SS is initialized, but they will continue to run as expected when gossip
is disabled. I think the only contentious issue should be that
{{isInitialized()}} is part of the {{StorageServiceMBean}} interface and this
changes its semantics slightly. In mitigation of that, I would argue that its
semantics were fairly unclear before, with the flag being set so early. The
bean also has redundant methods to obtain the gossip status already, so there's
no loss of information for clients here.
A side effect of setting {{isInitialized}} is that it also gives us what's
suggested [in this
comment|https://issues.apache.org/jira/browse/CASSANDRA-11537?focusedCommentId=15245412]
for CASSANDRA-11537.
I've also fixed all the other nits, and kicked off CI runs.
> Always require replace_address to replace existing address
> ----------------------------------------------------------
>
> Key: CASSANDRA-10134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10134
> Project: Cassandra
> Issue Type: Improvement
> Components: Distributed Metadata
> Reporter: Tyler Hobbs
> Assignee: Sam Tunnicliffe
> Labels: docs-impacting
> Fix For: 3.x
>
>
> Normally, when a node is started from a clean state with the same address as
> an existing down node, it will fail to start with an error like this:
> {noformat}
> ERROR [main] 2015-08-19 15:07:51,577 CassandraDaemon.java:554 - Exception
> encountered during startup
> java.lang.RuntimeException: A node with address /127.0.0.3 already exists,
> cancelling join. Use cassandra.replace_address if you want to replace this
> node.
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:543)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:783)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:720)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:611)
> ~[main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:626)
> [main/:na]
> {noformat}
> However, if {{auto_bootstrap}} is set to false or the node is in its own seed
> list, it will not throw this error and will start normally. The new node
> then takes over the host ID of the old node (even if the tokens are
> different), and the only message you will see is a warning in the other
> nodes' logs:
> {noformat}
> logger.warn("Changing {}'s host ID from {} to {}", endpoint, storedId,
> hostId);
> {noformat}
> This could cause an operator to accidentally wipe out the token information
> for a down node without replacing it. To fix this, we should check for an
> endpoint collision even if {{auto_bootstrap}} is false or the node is a seed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
