There are many reasons to use HTTP URLs instead of ZooKeeper. I think everyone should. It's not as battle-tested but let's work to change that, starting by *using* it.
https://issues.apache.org/jira/browse/SOLR-17605 I'll copy-paste the list: - Principled — ZooKeeper is conceptually behind Solr; clients shouldn’t talk to it. - Fewer dependencies for clients (no ZooKeeper or Netty). - Better security — only Solr should talk to ZooKeeper! Security settings and key configuration files are stored in ZooKeeper. - Eliminate the impact of ZK storage on clients. The change of where the configSet name was stored in ZK is an example. PRS is another. And other changes I’ve seen in a fork. - Reduce complexity of SolrJ from an operational standpoint and bug risks (e.g. no ZkStateReader there). No Zookeeper related configuration (jute.maxbuffer, etc.) - Reduce complexity of SolrCloud by limiting the range of use of key classes like ZkStateReader to only be in Solr instead of also existing in SolrJ. For example it’s not clear if/when LazyCollectionRef’s are used in SolrJ but with this separation, it’d be clearer that it couldn’t exist in SolrJ. - Increase our options for classes in solrj-zookeeper, like adding more dependencies (traces & metrics) without concern of burdening any user/client. - Reliably working with a collection after collection creation. If you’ve seen waitForActiveCollection after creating a collection in our tests, this is what I mean (and it’s not strictly a test issue!). It's sad; make them go away! On Tue, Oct 7, 2025 at 1:17 PM Chris Hostetter <[email protected]> wrote: > > In my opinion: > > 1) Using zkHost for SolrJ clients is the fastest, most reliable, most > efficient way to ensure all of your "trusted" SolrJ based Solr client > applications know about cluster & collection state changes. > > 2) The only reason to have SolrJ clients that are configured using Solr > URLs, is if you want to allow "untrusted" java applications to use SolrJ > to talk to your cluster, w/o giving those clients zk access. > > > -Hoss > http://www.lucidworks.com/ >
