[ 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)