[
https://issues.apache.org/jira/browse/CASSANDRA-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13444935#comment-13444935
]
Brandon Williams commented on CASSANDRA-4383:
---------------------------------------------
bq. The approach taken here continues to make me a little hesitant simply
because, I think, it introduces for the first time a need for proper ordering
of STATE transmission/reception. I don't have a clear-enough understanding of
how the underlying messaging works to know if we can firmly rely on that or not
In this case, it's ok, because SS only reacts to STATUS, so we can change any
other gossip state before changing that one and, regardless of how many gossip
events fire in the meantime, be guaranteed that other hosts react to the STATUS
update after all other gossip state changes are received.
bq. What I had in mind was (at least) something like a
sendState{Normal,Bootstrap,...}(Collection<token> tokens) to encapsulate those
operations sensitive to ordering. Gossiper.addLocalApplicationStates(...) still
makes it too easy to do the wrong thing.
That's basically syntactic sugar over
{{Gossiper.addLocalApplicationStates(...)}} which we'd still need as a building
block. I've given up on my previous attempt which actually did not provide
atomicity, and it looks like doing that would require rewriting EndpointState
to use the Reference and SnapTree approach similar to AtomicSortedColumns, and
that is way, way out of scope for this ticket (especially since we don't
actually need it)
bq. And in addition to getHostId, usesHostId also seems better suited to the
Gossiper.
You're right, updated patch moves those methods to Gossiper. I kept the name
{{getHostId}} there though since, by asking the gossiper, you should know
you're getting the hostId as it is *in gossip*, which may be a necessary thing
instead of tMD for non-ring members (or old removed members, or whatever.)
bq. But, mostly I meant that it doesn't read as well as the old code that
clearly did one thing when the version was < X, and another when it was >= Y.
That makes sense, I brought the old NET_VERSION checks back, but relocated to
the gossiper.
> Binary encoding of vnode tokens
> -------------------------------
>
> Key: CASSANDRA-4383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4383
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Brandon Williams
> Assignee: Brandon Williams
> Fix For: 1.2.0 beta 1
>
> Attachments:
> 0001-Add-HOST_ID-and-TOKENS-app-states-binary-serialization.txt,
> 0002-Fix-tests.txt
>
>
> Since after CASSANDRA-4317 we can know which version a remote node is using
> (that is, whether it is vnode-aware or not) this a good opportunity to change
> the token encoding to binary, since with a default of 256 tokens per node
> even a fixed-length 16 byte encoding per token provides a great deal of
> savings in gossip traffic over a text representation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
