Aleksey Yeschenko created CASSANDRA-12042:
---------------------------------------------
Summary: 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)
