[
https://issues.apache.org/jira/browse/CASSANDRA-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976114#action_12976114
]
Gary Dusbabek commented on CASSANDRA-1015:
------------------------------------------
I've swung back around to preferring that we use our own messages and
serialization for this. Adopting a framework like thrift or avro would save us
from the tedium of writing our own serialization methods, but would also take
away control over the serialization, which I don't think we want.
Here are a few examples of how I expect messages to change from version to
version:
1. a field is added. every framework handles this fine.
2. a field is removed. every framework handles this fine.
3. a field type is changed (name stays the same). every framework handles this
different. Thrift requires that we rename the field, which is the same as
removing and then adding a field. We'd need to have translation routines to
convert from the old field to the new one. Avro handles this a little bit
better using a union. But then the avro object type becomes a union which
would require ugly casting in our code. Using our own serialization would
solve this problem at serialization/deserialization time.
Given that a lot of our message format changes are of type 3, I think it makes
sense to stick with rolling our own messages. The only debt we incur is
maintaining the serialization methods, which hasn't been a substantial burden.
> 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.
