Sylvain Lebresne reassigned CASSANDRA-12042:

    Assignee: Sylvain Lebresne  (was: Stefania)

> 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: Sylvain Lebresne
>            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

Reply via email to