[ https://issues.apache.org/jira/browse/CASSANDRA-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joshua McKenzie updated CASSANDRA-12042: ---------------------------------------- Reviewer: Aleksey Yeschenko > 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 > Assignee: Stefania > 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)