[
https://issues.apache.org/jira/browse/CASSANDRA-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349795#comment-14349795
]
Stefania commented on CASSANDRA-8236:
-------------------------------------
{quote}
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
{quote}
That's clear now, thanks.
{quote}
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
{quote}
Yes I meant sending a String that can be converted into a TopologyChange event.
Before we go down this route however, could you check patch 8516-v2.1b.txt for
CASSANDRA-8516, where I added a new {{ApplicationState.STATUS}} called "MOVED"
to fix the mix-up between NEW_NODE and MOVED_NODE. I think originally you
wanted to do this for {{RPC_READY}} too but then settled for a new
{{ApplicationState}} flag. Why?
One more thing, this patch only delays "node added", not "node up", I assume
you are aware of this and it is OK.
> 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)
