[
https://issues.apache.org/jira/browse/SOLR-17630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17921462#comment-17921462
]
David Smiley commented on SOLR-17630:
-------------------------------------
SolrClientCache could be removed entirely in Solr 10 if we invest effort
accordingly. I'm just trying to clarify a path forward with incremental
progress without forcing us having to change everything everywhere at once
(i.e. remove SCC in one go). Perhaps we make CoreContainer.getSolrClientCache
deprecated. I'm thinking we should use deprecation liberally in our APIs, even
before we're ready to remove the thing.
> 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: 10m
> 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
