[
https://issues.apache.org/jira/browse/CASSANDRA-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349028#comment-14349028
]
Brandon Williams commented on CASSANDRA-8236:
---------------------------------------------
bq. VersionedValue.RPC_READY doesn't seemed to be used
You're right, can remove that on commit.
bq. In SS.handleStateNormal(), why do we need to call notifyJoined() even when
isMoving is set to true? Wouldn't this introduce problems similar to
CASSANDRA-8516?
It seems like it could, I didn't test with a moving node.
bq. In ApplicationState can we add a new value without removing one of the
padding values?
Let me explain the risk in padding values. Padding used to only have 5 values,
and in 1.1 we almost exceeded them which would break everything since the enum
lookup wouldn't resolve for some states, and that's catastrophic. That's why
we have the X_11_PADDING value from that near miss, and that's why I increased
the padding to 10 values. As long as the padding values aren't actually used,
it's better to have them than not. And that's why, I actually didn't remove one
:)
bq. Shouldn't we perhaps just add a new ApplicationState called TOPOLOGY_CHANGE
that contains the Event.TopologyChange value that a node wants a client to
receive?
I think that could work, but probably not by sending Event.TopologyChange
itself, since we can only send a VersionedValue. That's an implementation
detail though and shouldn't be hard to solve.
> Delay "node up" and "node added" notifications until native protocol server
> is started
> --------------------------------------------------------------------------------------
>
> Key: CASSANDRA-8236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8236
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Tyler Hobbs
> Assignee: Brandon Williams
> Fix For: 3.0
>
> Attachments: 8236.txt
>
>
> As discussed in CASSANDRA-7510, there is still a gap between when a "node up"
> or "node added" notification may be sent to native protocol clients (in
> response to a gossip event) and when the native protocol server is ready to
> serve requests.
> Everything in between the call to {{StorageService.instance.initServer()}}
> and creation of the native server in {{CassandraDaemon.setup()}} contributes
> to this delay, but waiting for Gossip to settle introduces the biggest delay.
> We may need to introduce a "STARTING" gossip state for the period inbetween,
> which is why this is scheduled for 3.0. If there's a better option, though,
> it may make sense to put this in 2.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
