[
https://issues.apache.org/jira/browse/SOLR-17630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17926974#comment-17926974
]
ASF subversion and git services commented on SOLR-17630:
--------------------------------------------------------
Commit 158074d40f271a0d5afd3698ebbe333d1820e598 in solr's branch
refs/heads/main from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=158074d40f2 ]
SOLR-17630 Add SolrCloudManager.getSolrClient (#3049)
and ZkController.getSolrClient for a canonical node managed CloudSolrClient.
Deprecate SolrCloudManager.request
Deprecate CoreContainer.getSolrClientCache
> Add CloudSolrClient instance for a Solr node
> --------------------------------------------
>
> Key: SOLR-17630
> URL: https://issues.apache.org/jira/browse/SOLR-17630
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: David Smiley
> Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> There ought to be a general CloudSolrClient instance for the Solr node,
> without each potential user of such needing to create one. The closest
> substitute at the moment is
> {{cc.getSolrClientCache().getCloudSolrClient(cc.getZkController().getZkServerAddress())}}
> which is too verbose, not as discoverable, and it's debatable if
> SolrClientCache should be it's home.
> A scalability/simplicity advantage of a shared one instead of newly
> constructed one is that the existing ZkClientClusterStateProvider (same node
> ZkStateReader instance) can be used, thus improving scalability and
> simplifying interpretation of logs (as all logs from ZkStateReader on a node
> can be assumed to then be from the same instance). SolrClientCache creates
> new ones.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
