[
https://issues.apache.org/jira/browse/SOLR-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14339947#comment-14339947
]
Alan Woodward commented on SOLR-4044:
-------------------------------------
Moving the conversation over from SOLR-7146...
bq. Seems like clients should normally be read-only w.r.t. ZK.
This isn't the case at the moment -
ZkStateReader.createClusterStateWatchersAndUpdate already calls ensureExists()
on the aliases and clusterstate.json znodes. I agree that it sounds like a
good idea, though.
Maybe a nicer way forward would be:
* throw a 503 SolrServerException if any of the watcher nodes don't exist in
ZkStateReader when cCSWAU is called
* add a sugar waitForCluster(timeout) method to CloudSolrClient that will
repeatedly check zk for the relevant nodes
Also, if we want to really ensure that clients never actually change ZK, we
could add a ReadOnlyZkClient that subclasses SolrZkClient and throws UOE on
makePath() and setData(), and make CloudSolrClient use that.
> CloudSolrServer early connect problems
> --------------------------------------
>
> Key: SOLR-4044
> URL: https://issues.apache.org/jira/browse/SOLR-4044
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.0
> Reporter: Grant Ingersoll
> Assignee: Mark Miller
> Priority: Minor
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-4044.patch
>
>
> If you call CloudSolrServer.connect() after Zookeeper is up, but before
> clusterstate, etc. is populated, you will get "No live SolrServer" exceptions
> (line 322 in LBHttpSolrServer):
> {code}
> throw new SolrServerException("No live SolrServers available to handle this
> request");{code}
> for all requests made even though all the Solr nodes are coming up just fine.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
