[
https://issues.apache.org/jira/browse/ZOOKEEPER-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586462#comment-13586462
]
Alexander Shraer commented on ZOOKEEPER-1633:
---------------------------------------------
The intention is for this patch to be in 3.4.6. It will have no effect on 3.4.5
and 3.4.6 normal operation, since they will not send
a protocol number, they'll send their id. Starting with 3.5.0, we'll send the
protocol number first, and this patch will allow a 3.5.0 server to connect to a
3.4.6 server. Of course if a 3.5.0 server tries to connect to a 3.4.5 server
(that doesn't have the patch) we'll get the error message above (so if you get
the errors above this means you haven't applied the patch, Patrick asked me to
document this).
My intention was to start sending the protocol version starting with 3.5.0 in
future releases too and this is part of zk-107 that already does it.
In my view this has absolutely no effect on 3.4 since the code will never run
until a 3.5.0 or later server tries to connect (the if in the patch will be
false since before 3.5.0 servers send their id first, which is positive).
I tested this with servers running trunk + zk-107 connecting to servers running
3.4 + this patch.
> 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
