[
https://issues.apache.org/jira/browse/CASSANDRA-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16577140#comment-16577140
]
Sylvain Lebresne commented on CASSANDRA-12042:
----------------------------------------------
bq. Is this REALLY a blocker for 4.0, or just something we hoped would land?
The latter, and I've update the priority accordingly. Also realized that was
assigned to me and that is my bad, as I haven't really started on this and
don't have time to work on it. So clearly not 4.0 imo.
As an aside, I did take a few cycles just looking at how to implement this in
practice, and I think this is more involved that what the description suggests
in practice, at least to do cleanly. Reasons including that all responses have
the same {{VERB}}, making the version for that {{VERB}} still covering
unrelated things (which is not ideal), or that we have quite a few {{VERB}} and
it's not immediately clear, to me at least, how we have a version for each but
still keep things manageable (once we start actually making changes to
different parts that is).
> Decouple messaging protocol versioning from individual message types
> --------------------------------------------------------------------
>
> Key: CASSANDRA-12042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12042
> Project: Cassandra
> Issue Type: Improvement
> Components: Streaming and Messaging
> Reporter: Aleksey Yeschenko
> Priority: Major
> Fix For: 4.x
>
>
> At the moment we have a single constant -
> {{MessagingService.current_version}} defining serialization format for
> *everything*, including every possible message type.
> In practice it means that any tiniest change to any message requires bumping
> the global {{MessagingService}} version.
> This is problematic for several reasons, the primary of which is currently
> the schema propagation barrier between differently versioned C* nodes. In
> tick-tock world, it means that any change (say, to a read command message),
> would require a messaging service bump, putting nodes on split versions of
> the service, and making schema changes during this now considered minor
> upgrade, impossible, which is not neat.
> I propose that starting with 4.0 we version all messages individually
> instead, and separately version messaging service protocol itself - which
> will basically amount to just framing, once CASSANDRA-8457 is completed.
> In practice, this might be implemented the following way:
> # We use an extra byte with each message to specify the version of that
> particular message type encoding
> # Instead of relying on messaging service of the sending note (determining
> which can be racy, especially during upgrades), we use that byte to determine
> the version of the message during deserialisation
> # On sending side, we can use the gossipped version of Cassandra itself - not
> the messaging service version - to determine the maximum supported message
> type version of the destination node
> In the new world, I expect the framing protocol version to change very rarely
> after 4.0, if ever, and most message types to change extremely rarely as
> well, with schema, read, and write messages to change version most often.
--
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
