[
https://issues.apache.org/jira/browse/CASSANDRA-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933178#action_12933178
]
Gary Dusbabek commented on CASSANDRA-1015:
------------------------------------------
I've thought about this and done a bit of hacking (had 0.7 mostly on speaking
terms with 0.6). Here is how I think we ought to proceed:
Version N should be able to translate messages to and from N-1 in the N-1
format. N-1 should be oblivious to the fact that it's speaking to a newer
node.
This gets tricky because in some cases we take a message and send it to several
nodes. We'll have to transcode that message in-place for older nodes. This
will degrade performance somewhat, but we need to recognize that this is a
temporary state for the cluster.
As long as there is a facility to transcode any message between N and N-1,
we'll be set. This means changing the CompactSerializer API to respect a
version identifier (probably a boolean to indicate oldVersion), which touches
quite a bit of code.
The version in the message header will start to mean something and will get
upgraded for every major version and stuffed into the message itself. This
will enable N to detect a N-1 message.
We'll need a test suite that contains pre-serialized messages from the N-1
version to verify that the current version is the same or that we can properly
translate from that version.
I'm pretty sure I can have this done in about a week, but I don't want to start
until trunk==0.8.
> Internal Messaging should be backwards compatible
> -------------------------------------------------
>
> Key: CASSANDRA-1015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1015
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Ryan King
> Assignee: Gary Dusbabek
> Priority: Critical
> Fix For: 0.8
>
>
> Currently, incompatible changes in the node-to-node communication prevent
> rolling restarts of clusters.
> In order to fix this we should:
> 1) use a framework that makes doing compatible changes easy
> 2) have a policy of only making compatible changes between versions n and n+1*
> * Running multiple versions should only be supported for small periods of
> time. Running clusters of mixed version is not needed here.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
