[
https://issues.apache.org/jira/browse/CURATOR-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zili Chen resolved CURATOR-704.
-------------------------------
Assignee: Zili Chen
Resolution: Fixed
master via
https://github.com/apache/curator/commit/82f2e53459d4905efaedc47493cedb649d934e46
> Use server version to detect supported features
> -----------------------------------------------
>
> Key: CURATOR-704
> URL: https://issues.apache.org/jira/browse/CURATOR-704
> Project: Apache Curator
> Issue Type: Improvement
> Components: Client
> Affects Versions: 5.6.0
> Reporter: Laurent Goujon
> Assignee: Zili Chen
> Priority: Major
> Fix For: 5.7.0
>
>
> According to documentation Curator is compatible with ZooKeeper 3.5 and
> higher, but feature detection is based on the version of the ZooKeeper client
> shipped with Curator, not based on the actual version of the server the
> client is connected to. Ideally it should be based on both.
>
> As ZooKeeper client is backward compatible with older servers (see
> [https://zookeeper.apache.org/releases.html] `ZooKeeper 3.9.x clients are
> compatible with 3.5.x, 3.6.x, 3.7.x and 3.8.x servers as long as you are not
> using new APIs not present these versions.`), applications using the
> zookeeper client will use a possibly more recent version for bugfix/security
> reasons while the server (which is not controlled by the application) may
> still be on an older version. This is a frequent scenario for application
> developed for Hadoop environment with Cloudera installations still based on
> ZK 3.5.5.
> As a solution, it should be possible to instruct curator client/framework to
> specify a baseline zookeeper version (better would be to detect the remote
> version and adjust) and to disable unavailable features even if supported by
> the ZooKeeper client
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
