[
https://issues.apache.org/jira/browse/SOLR-17605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-17605:
--------------------------------
Description:
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!
was:Vision: make the HTTP ClusterStateProvider (Solr URLs) be the primary
(only?) way that users use CloudSolrClient. This will track some related
improvements as well, albeit mayn't be strictly required for this vision.
> 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]
