Hey Shawn, A few answers, where I can give them.
1. It's easy to miss in the thread, but the user mentioned that they're creating their CloudSolrClient via solr URLs. 2. When you create a CloudSolrClient with a Solr URL, it's not just used to fetch the ZK connString so that it can use ZK from then on. It continues to use the Solr URL for fetching cluster state. If you're curious, the codepaths are "ZkClientClusterStateProvider", and "HttpClusterStateProvider", respectively. I don't know much about the ClusterStateProvider implementations to say anything more helpful about the original problem, but figured I'd chime in where I could. Best, Jason On Wed, Nov 7, 2018 at 12:42 PM Shawn Heisey <apa...@elyograg.org> wrote: > > On 11/6/2018 10:06 PM, Gus Heck wrote: > > One thing that causes a clusterstatus call is alias resolution if the > > HttpClusterStateProvider is in use instead of the ZkClusterStateProvider. > > I've just been fixing spurious error messages generated by this > > in SOLR-12938. > > Gus, > > If CloudSolrClient is created using URLs instead of a zkHost, does it do > EVERYTHING with http instead of ZK? Because if it does, it might > actually make sense for it to initiate lot of http requests. The ZK > client is capable of nearly instantaneous notification of cluster > changes ... duplicating that with HTTP would require constant checking. > > What I would have hoped for when constructing CloudSolrClient with URLs > was that it would ask the server(s) for the zkHost setting, and then > proceed to use ZK. But I suppose if you're using URLs because ZK isn't > reachable, that would be problematic. > > Thomas, > > Are you initializing CloudSolrClient with your ZK server info, or using > one or more Solr URLs? > > Thanks, > Shawn >
