[
https://issues.apache.org/jira/browse/ZOOKEEPER-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586378#comment-13586378
]
Flavio Junqueira commented on ZOOKEEPER-1633:
---------------------------------------------
[~shralex] the idea of adding a protocol version sounds like a good one, but
I'm wondering how this patch is going to work out. If a 3.5.0 server tries to
connect to a 3.4.5 server, then I believe it will be dropping the connection
according to the log messages above. I forgot exactly how it goes, but I think
the one with highest id is supposed to start the connection. If that's the
case, then the two servers will never be able to establish a connection.
About the protocol version, I suppose it wouldn't hurt to have it in future
versions too, it is a good practice and we should have done it before. It might
be a good idea to create a jira for it if you don't want to this feature more
generally.
I was also wondering if we need a test here. Since this is just to enable
migrations from 3.4.5 to 3.5.0, it is not necessary to guarantee no regression
in future 3.5.0, but we might need to make sure that the 3.4 remains correct.
What do you think?
> Introduce a protocol version to connection initiation message
> -------------------------------------------------------------
>
> Key: ZOOKEEPER-1633
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1633
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Reporter: Alexander Shraer
> Assignee: Alexander Shraer
> Fix For: 3.4.6
>
> Attachments: ZOOKEEPER-1633.patch
>
>
> Currently the first message a server sends to another server includes just
> one field - the server's id (long). This is in QuorumCnxManager.java. This
> makes changes to the information passed during this initial connection very
> difficult. This patch will change the first field of the message to be a
> protocol version (a negative number that can't be a server id). The second
> field will be the server id. The third field is number of bytes in the
> remainder of the message. A 3.4 server will read the first field as before,
> but if this is a negative number it will read the second field to find the
> server id, and then remove the remainder of the message from the stream. This
> will not affect 3.4 since 3.4 and earlier servers send just the server id (so
> the code in the patch will not run unless there is a server > 3.4 trying to
> connect). This will, however, provide the necessary flexibility for future
> releases as well as an upgrade path from 3.4
--
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
