[
https://issues.apache.org/jira/browse/SOLR-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268329#comment-15268329
]
Shai Erera commented on SOLR-9057:
----------------------------------
I thought that the whole idea of CSC is to use ZkStateReader so that it can
react to state changes quickly, because ZkStateReader does create a watch on
the cluster state. If it doesn't use ZkStateReader anymore, will it
periodically poll CLUSTERSTATUS? Isn't that less efficient and maybe even doing
a lot of redundant CLUSTERSTATUS checks when the cluster state doesn't change?
I always viewed CSC and its use of ZkStateReader as an advantage. I do
understand though that it currently plays two roles, which I believe you
propose to separate: (1) understanding the distributed topology of the Solr
nodes, so that it forwards requests to leaders etc. and (2) getting notified on
cluster state changes rather than querying for it repeatedly.
I personally think that CSC should continue to use ZkStateReader and be tied to
it. Users who don't want to expose/get-exposed to ZK can use a regular
HttpSolrClient. True, their requests may get routed to the right node (so that
adds an extra hop), but perhaps it's not that bad?
Alternatively, you could have CSC take a ClusterStateProvider with two impls:
one that uses HTTP CLUSTERSTATUS and another that uses ZkStateReader. Then
users can enjoy the best of both worlds: CSC does the "right" thing and the
user can choose whether to work w/ the HTTP end-point or the ZK one.
> CloudSolrClient should be able to work w/o ZK url
> -------------------------------------------------
>
> Key: SOLR-9057
> URL: https://issues.apache.org/jira/browse/SOLR-9057
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
> Reporter: Noble Paul
>
> It should be possible to pass one or more Solr urls to Solrj and it should be
> able to get started from there. Exposing ZK to users should not be required.
> it is a security vulnerability
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
