[
https://issues.apache.org/jira/browse/CASSANDRA-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15341698#comment-15341698
]
Jason Brown commented on CASSANDRA-12042:
-----------------------------------------
I like this idea idea, and adding a version to the frame post CASSANDRA-8457
will be largely trivial. We can retain the {{MessagingService.current_version}}
to represent the protocol version, which defines the handshake interaction, the
framing format, and so on.
However, one tiny discrepancy is that {{MessagingService.current_version}} is a
four byte integer in the protocol, while we are proposing to use a byte for the
message version. In practice, this is probably won't be a problem, unless we
need to rev a message's version to > 255, but hopefully we've all retired to
beach estates by then ;). We could also use VInt, but perhaps it's not even
worth bothering with that.
> 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
(v6.3.4#6332)
