Hi, We always check how the zookeeper ensemble is configured, and this check does not depend on whether dynamic reconfiguration is possible or not, it is simply to detect the common mistake that a 3 node ensemble is addressed with only one of the hosts in the static config, or with wrong host names.
Sounds like your problem is not with how Solr talks to ZK, but in how you have configured your network. You say > But this will cause the socket connect to block when resolving > "0.0.0.0" which makes everything very slow. Can you elaborate on exactly which connection you are talking about here, and why/where it is blocking? Can you perhaps attempt a few commands from the command line to illustrate your point? Assuming you are on Linux, and have the 'time' command available, try this export ZK_HOST=my-zookeeper:2181 time server/scripts/cloud-scripts/zkcli.sh -z $ZK_HOST -cmd get /zookeeper/config time server/scripts/cloud-scripts/zkcli.sh -z $ZK_HOST -cmd ls /live_nodes time server/scripts/cloud-scripts/zkcli.sh -z $ZK_HOST -cmd get /configs/_default/stopwords.txt What kind of timings do you see? Jan > 14. des. 2022 kl. 13:23 skrev michael dürr <due...@gmail.com>: > > Hi, > > Since we have updated to Solr 9.1, the admin ui has become pretty slow. > > The problem is related to the fact that we run solr and the zookeeper > ensemble dockerized. As we cannot bind zookeeper from docker to its host's > external ip address, we have to use "0.0.0.0" as the server address which > causes problems when solr tries to get the zookeeper status (via > /solr/admin/zookeeper/status) > > Some debugging showed that ZookeeperStatusHandler.getZkStatus() always > tries to get the dynamic configuration from zookeeper in order to check > whether it contains all hosts of solr's static zookeeper configuration > string. But this will cause the socket connect to block when resolving > "0.0.0.0" which makes everything very slow. > > The approach to check whether zookeeper allows for dynamic reconfiguration > is based on the existence of the znode /zookeeper/config which seems not to > be a good approach as this znode will exist even in case the zookeeper > ensemble does not allow dynamic reconfiguration (reconfigEnabled=false). > > Can anybody suggest some simple action to avoid that blocking (i.e. the > dynamic configuration check) in order to get the status request return fast > again? > > It would be nice to have a configuration parameter that disables this check > independent of the zookeeper ensemble status. Especially as > reconfigEnabled=false is the default setting for zookeeper. > > Thanks, > Michael
