>> I don’t see any indication when It will jump to beta or even stable.
The ZooKeeper community is working on getting a Release Candidate of 3.5.3 beta build very soon (in a matter of weeks). So optimistically speaking we will reach beta very soon and hopefully have a stable release after that. >> Whether any code changes will be required in Solr to take advantage of dynamic reconfiguration after the dependency upgrade Some code change might be required depend on use cases, as ZooKeeper client library currently does not handle everything transparently for you. As an example, if the quorum membership changed, then clients should detect this change, retrieve the up to date server list, and do a reconnect if applicable (i.e. if the current server client connects to is taken out of quorum). There are work to improve the user experience of clients by abstracting more details inside ZooKeeper client library, such as ZOOKEEPER-2016 (client side rebalancing). >> Whether a Solr instance with the 3.5 client could be told about only one ZK server, then discover the whole cluster and connect to all the servers Client could be told with just one server and then discover rest of the ensemble through ZooKeeper.getConfig API, which returns the up to date server list. Client can set watchers on getConfig API to get notified when membership changes and react accordingly, as previously mentioned. On Thu, Jan 5, 2017 at 12:41 PM, Shawn Heisey <[email protected]> wrote: > On 1/5/2017 11:19 AM, Washko, Daniel wrote: > > Thanks for the reply Shawn. I would like to clarify something though. > > Right now, the Dynamic Reconfiguration of Zookeeper works for > > Zookeeper – that is adding/removing nodes automatically without having > > to reconfigure each zookeeper node manually. Once Zookeeper is out of > > Alpha then Solr will be updated to take advantage of the Dynamic > > Reconfiguration capability of Zookeeper and auto-discover any changes. > > Is that correct? > > I am not sure whether my understanding is correct, but if it is, then I > don't think a zookeeper 3.4.x client (like the one in Solr) will notice > that the server list (with servers running 3.5.x) has changed. > Depending on exactly how the membership changed, the SolrCloud instance > might not be able to maintain a viable ZK quorum. If it loses quorum, > SolrCloud goes read-only. > > After ZK 3.5 goes through the beta phase and reaches stable, then Solr > will get the upgrade, and we will make sure that the dynamic > reconfiguration works. It's a feature that we definitely want, though > we may wait for the second or third stable release before we upgrade to > be absolutely certain that it's solid. > > There are a couple of questions I do not know the answer to: 1) Whether > any code changes will be required in Solr to take advantage of dynamic > reconfiguration after the dependency upgrade. 2) Whether a Solr > instance with the 3.5 client could be told about only one ZK server, > then discover the whole cluster and connect to all the servers. Can a > more knowledgeable member of this community answer these questions for me? > > Thanks, > Shawn > > -- Cheers Michael.
