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

Gary Dusbabek commented on CASSANDRA-1970:
------------------------------------------

bq. hang on, don't we already have a per-message version field in the message 
first-bytes-sent? i think it's reasonable to say...
Yes.  That is the "envelope" supplied by MS.packit().  We need to adhere to the 
first 8 bytes of that format forever.  Once we know the version, we have a lot 
of flexibility, meaning that the wire format for o.a.c.net.Message can change 
whenever we need it to.

bq. it only restricts gossip, which isn't A Big Deal since it's so little 
traffic.
There are two problems with this.  First, it locks us down to the serialization 
outlined in MessageSerializer (to include HeaderSerializer).  That removes a 
lot of flexibility if we are ever interested in changing those formats.  
Second, it introduces two code paths by special casing gossip messages.

bq. so how about this? we try to parse gossip packets in the current version; 
if that fails, we parse in the old version
That wouldn't work if a N node was trying to join a cluster of N-1 nodes.  (The 
N-1 nodes can't speak a protocol from the future.)

What if, when communication starts up, messages are sent in the current format 
and the previous format until for format of the destination is known (after a 
response is received)?  Kind of a hack, but it avoids bouncing, locking 
serialization formats and special casing gossip messages.

> Message version resolution
> --------------------------
>
>                 Key: CASSANDRA-1970
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1970
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Gary Dusbabek
>            Assignee: Gary Dusbabek
>            Priority: Minor
>             Fix For: 0.8
>
>
> When a new new node (version N) contacts an old node (version N-1) for the 
> first time, the old node will not understand the message.  One resolution 
> mechanism would be for the old node to "bounce" the message back to the 
> sender.  The sender would then respond by translating the message to the 
> appropriate version and resending it.
> For this to work, 0.7.1 will need to have the "bounce" feature.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to