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

Sylvain Lebresne commented on CASSANDRA-5436:
---------------------------------------------

bq. sets a version on the incoming message, to be able to serialize for an old 
client

Looks mostly good but in the case an exception is raised, the version won't be 
set correctly. We should set it in the catch block of 
Dispatcher.messageReceived (like we do for StreamId).

bq. the client sends a StartupMessage, and if that has the wrong version, we 
just disconnect

I think we at least send an error message before disconnecting. There is that 
at least :)

bq. would perhaps be nice if the server ignored this version if it is higher 
than what it supports and replies with a Ready/Authenticate-message with 
CURRENT_VERSION

That would work I think.

Though I'll mention another option that would be to ignore the protocol version 
for the OPTIONS message instead, and respond with a SUPPORTED message that have 
the same version than the message received, but that includes which protocol 
versions the server support.  I'm suggesting that because I feel it might be 
simpler for clients if we always respond to their message with the same version 
they sent us, but also because it feels that this kind of 'whats supported' 
business is why the OPTIONS/SUPPORTED messages exists in the first place.

I do note however that it's probably a tad too late for 1.2. So clients of the 
v2 protocol will probably have to handle the case where they get an exception 
on startup and special case to try v1 in that case.

Otherwise, I've forked the protocol spec, so we can document change we make for 
v2 while we make it. I've added a 'Changes since v1' to the v2 spec, so client 
implementors have an easy changelog to upgrade to v2 (without needing to diff 
the spec that is).

                
> Binary protocol versioning
> --------------------------
>
>                 Key: CASSANDRA-5436
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5436
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Marcus Eriksson
>         Attachments: 0001-CASSANDRA-5436.patch
>
>
> There should be a way to version the binary protocol, CASSANDRA-5349 adds a 
> message that breaks compatibility (QueryMessage) and the ticket half-handles 
> versioning - it allows old clients to connect and execute queries (by always 
> replying in the same version as the message sent by the client), it does not 
> allow new clients to connect to old servers though.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to