zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Han <h...@apache.org>
Subject Re: A question about cross-version client/server compatibility
Date Wed, 23 May 2018 04:32:06 GMT
Please check out Backward Compatibility section in
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement.

A few other comments inline.

On Tue, May 22, 2018 at 2:47 PM, Shawn Heisey <apache@elyograg.org> wrote:

> Somebody on the solr-user mailing list has posed a question about
> whether they can use ZK 3.4.12 on the server side and a specific version
> of Solr on the client side.  The specific version of Solr they're asking
> about includes ZK 3.4.10 for its client code.
>
> I would not anticipate any issues running with 3.4.10 on the client side
> and 3.4.12 on the server side, so I think I can safely answer their
> question, but I have a more general question to ask.
>
> Are there ANY mixed version matchups that present problems, assuming the
> server is running a newer version than the client?  I would never advise
> running a server version that's older than the client.
>

If the mixed versions are not compatible (see the reference in the link),
there might be problems.


>
> The very first release of Solr to feature ZK integration was 4.0-ALPHA,
> and eventually the stable 4.0.0 release, which included ZK 3.3.6.  The
> subsequent version of Solr, which was 4.1.0, included ZK 3.4.5.  We
> expect to include ZK 3.4.12 with the next release of Solr - 7.4.0.
>
> I did a simple test with Solr 4.0.0 against a single ZK 3.4.12 server.
> It started just fine.  The testing was not exhaustive, but I saw zero
> problems.
>
> What I intend to say on the solr-user thread is that ZK 3.4.12 can be
> used with ALL SolrCloud versions, but I thought I should sanity-check
> that statement here before I make it.
>

ZK 3.4.x is compatible with ZK 3.3.y releases (major.minor is compatible
with major.(minor-1)), so in your case this statement should be true.


> Thanks,
> Shawn
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message