[ 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