I'm really confused by this bq: I am proposing that the Collection API be consistent...
How can it? The collections API simply allows collection manipulation (creation, deletion and the like) through an HTTP call. Where do you think it _can_ get any intelligence about the cluster state? There's no "there" there. Or are we talking about submitting queries as opposed to the Collections API? Again, the design here is to accept any incoming HTTP request so you'd have to intercept the HTTP request somewhere and then "do the right thing" with it. And this is what CloudSolrClient already does. If you're thinking of some kind of non-java layer to route things, then the you can get the status from Zookeeper through HTTP calls to Solr (or indeed, call Zookeeper directly) to make those decisions. So I really don't understand the proposal at all. Best, Erick On Tue, May 3, 2016 at 10:26 AM, <wmcgin...@cox.net> wrote: > I am proposing that the Collection API be consistent with SolrJ > (CloudSolrClient). > SolrJ's design philosophy uses the list of zookeeper addresses to gather > cloud information, > and then intelligently sends the actual request to the single solr node that > is best able to serve it. > This information includes what solr nodes are alive, and what > collections/cores reside, > and where and whom the current leader is. > > Why can't the Collection API or something else expose this functionality. > Otherwise, you have to use a load balancer (software or hardware) to present > a single point of access for your code, > and let it forward the request to one of the solr nodes. It should be able > to track which ones are alive and failover to the other(s). > I really don't think this is necessary, because Solr can already do this, > internally. > > Maybe an intelligent way of submitting queries to the cloud, without checking > the cloud state > is difficult, but the code already exists. > > Thank you > Will McGinnis
