cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-12042) Decouple messaging protocol versioning from individual message types
Date Tue, 21 Jun 2016 12:44:57 GMT

    [ 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)

Mime
View raw message