[
https://issues.apache.org/jira/browse/CASSANDRA-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne reassigned CASSANDRA-12042:
--------------------------------------------
Assignee: (was: Sylvain Lebresne)
> 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: Blocker
> Fix For: 4.0
>
>
> 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
