[
https://issues.apache.org/jira/browse/ZOOKEEPER-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399219#comment-13399219
]
nkeywal commented on ZOOKEEPER-1381:
------------------------------------
Ok, from what you're saying, I understand that looking for a version on a ZK
cluster is not that simple, as we can have servers with a different version and
these versions can change if the ZK administrator is currently
upgrading/downgrading this cluster.
But whenever we use a function (like multi) not available on all ZK versions,
we code our client against an explicit version. I was looking for:
1) Having a clear error when starting the application, by checking the ZK
version (like: "This application requires a ZK 3.4+ server, and yours is only
3.3.2. Please upgrade it"). As it's not that simple to have something 'clean',
the best solution would be to close this jira.
1.1) A second use case was to have two implementations in the client, one for
3.3 server and one for 3.4+ and dynamically choosing the one to use from the
version returned by the ZK cluster. But I'm happy to drop this one.
2) When using 'multi' with a wrong ZK server, get a clear error (a la "unknown
function, this server is in 3.3, may be you're looking for something available
only in a later version"), instead of a hanging client. I understand his would
mean patching 3.3 versions as well and it will be useful when the patched
versions will be generalized.
So if I sum up everything, it seems that the conclusion is:
- the workaround with 'nc' mentioned in the bug description is the best way to
get a (somehow limited) safety network against simple deployment mistakes when
using new ZK functions like multi.
- As such, we can close this jira and we're done. :-)
> Add a method to get the zookeeper server version from the client
> ----------------------------------------------------------------
>
> Key: ZOOKEEPER-1381
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1381
> Project: ZooKeeper
> Issue Type: Improvement
> Components: c client, documentation, java client, server
> Affects Versions: 3.4.2
> Environment: all
> Reporter: nkeywal
> Priority: Minor
> Labels: newbie
>
> Zookeeper client API is designed to be server version agnostic as much as
> possible, so we can have new clients with old servers (or the opposite). But
> there is today no simple way for a client to know what's the server version.
> This would be very useful in order to;
> - check the compatibility (ex: 'multi' implementation available since 3.4
> while 3.4 clients API supports 3.3 servers as well)
> - have different implementation depending on the server functionalities
> A workaround (proposed by Mahadev Konar) is do "echo stat | nc hostname
> clientport" and parse the output to get the version. The output is, for
> example:
> -----------------------
> Zookeeper version: 3.4.2--1, built on 01/30/2012 17:43 GMT
> Clients:
> /127.0.0.1:54951[0](queued=0,recved=1,sent=0)
> Latency min/avg/max: 0/0/0
> Received: 1
> Sent: 0
> Outstanding: 0
> Zxid: 0x500000001
> Mode: follower
> Node count: 7
> --------------------
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
