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 Thu, 18 Nov 2010 01:25:14 GMT

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

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

bq. I would prefer if we'd reuse a serialization scheme that handles said compatibility (avro,
thrift, etc), rather than inventing our own system.
Schema migration serialization became brittle when we introduced avro serialization to it.
 I haven't been impressed with it so far, but I'm willing to concede that maybe we're doing
it wrong.

How will avro handle the situation where we've been sending a field as a string, but we decide
to convert it to an enum and send it as an int in the future for compactness?  (This is par
for the course.)  Or fields previously required fields a, b and c are removed and replaced
with required fields d, e, f, g and h (also par for the course)?

If we used something like thrift or avro, we would need to deal with the complexity of handling
the current 0.7 messages which is not thrift/avro in parallel with the 0.8 format.  In this
case I'd argue for opening up another storage port and just run two protocols for the time
being.

> 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