cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Dusbabek (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1015) Internal Messaging should be backwards compatible
Date Wed, 26 Jan 2011 21:22:46 GMT

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


Mime
View raw message