[
https://issues.apache.org/jira/browse/SOLR-17605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18089739#comment-18089739
]
Vishnu Priya commented on SOLR-17605:
-------------------------------------
Assigning this issue to myself.
> Umbrella: CloudSolrClient: HTTP ClusterStateProvider
> ----------------------------------------------------
>
> Key: SOLR-17605
> URL: https://issues.apache.org/jira/browse/SOLR-17605
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Priority: Major
>
> Vision: make the HTTP ClusterStateProvider (Solr URLs) be the primary (only?)
> way that users use CloudSolrClient. The solrj-zookeeper module should
> eventually be absorbed into Solr. This will track some related improvements
> as well, albeit may not be strictly required for this vision.
> [dev-list
> thread|https://lists.apache.org/thread/tvpvokb7xnnnzc02ksmph4jy1qyl3mcc]
> Why:
> * 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!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
