You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Gary Dusbabek (JIRA)" <ji...@apache.org> on 2011/01/26 22:22:46 UTC

[jira] Commented: (CASSANDRA-1015) Internal Messaging should be backwards compatible

    [ https://issues.apache.org/jira/browse/CASSANDRA-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987227#action_12987227 ] 

Gary Dusbabek commented on CASSANDRA-1015:
------------------------------------------

For this iteration, I decided to stick with our homegrown serialization (ICompactSerializer).  I'm not opposed to an approach that uses avro/thrift/whatever messages though.  I ended up spending a few days trying to use avro for messages and keep compatibility with 0.7, but I decided it was tacking too many problems at once (backwards compatibility, whole new set of messages).

If the community (not just you Twitter guys!) wants to move towards an avro-based message format, perhaps we could try this process:
1. 0.7+1 use backward compatible homegrown messages.
2. 0.7+2 introduce avro messages. We'll probably have to listen on two ports during this phase since the message binary format will be VASTLY different between the two versions.
3. 0.7+3 all avro, all the time.
4. ... at this point, all that will need to be changed between versions is the code that translates FooMessage from the previous version to the next version.

> 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.