We send all updates to the load balancer, so they’ll end up on the wrong shard, not on the leader, etc. Indexing speed is still limited by the CPU available on each leader. I don’t think that sending the update to the right leader makes any improvement in throughput.
On the other hand, the CloudSolrClient ignores errors from Solr, which makes it unacceptable for production use. I would stay with your current indexing client and worry about something else. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Feb 11, 2019, at 8:15 AM, Emir Arnautović <emir.arnauto...@sematext.com> > wrote: > > Hi Boban, > Not sure if there is Solrj port to Go, but you can take that as model to > build your ZK aware client that groups and sends updates to shard leaders. I > see that there are couple of Solr Go clients, so you might first check if > some already supports it or if it makes sense that you contribute that part > to one of your choice. > > Emir > -- > Monitoring - Log Management - Alerting - Anomaly Detection > Solr & Elasticsearch Consulting Support Training - http://sematext.com/ > > > >> On 11 Feb 2019, at 16:09, Boban Acimovic <b...@it-agenten.com> wrote: >> >> Thank you Emir for quick reply. I use home brewed Go client and write just >> to one of 12 available nodes. I believe I should find out this smart way to >> handle this :) >> >> >> >> >>> On 11. Feb 2019, at 15:21, Emir Arnautović <emir.arnauto...@sematext.com> >>> wrote: >>> >>> Hi Boban, >>> If you use SolrCloud Solrj client and initialise it with ZK, it should be >>> aware of masters and send documents in a smart way. >>> >>> HTH, >>> Emir >>> -- >>> Monitoring - Log Management - Alerting - Anomaly Detection >>> Solr & Elasticsearch Consulting Support Training - http://sematext.com/ >> >
