And the other large benefit of CloudSolrClient is that it routes documents directly to the correct leader, i.e. does the routing on the client rather than have the Solr instances forward docs to the routing. Using CloudSolrClient should scale more nearly linearly with increasing shards.
Best, Erick On Fri, Nov 6, 2015 at 6:39 AM, Shawn Heisey <apa...@elyograg.org> wrote: > On 11/6/2015 7:15 AM, Vincenzo D'Amore wrote: >> I have followed your same path, having a look at java source. I inherited >> an installation with CloudSolrServer (I still had solrcloud 4.8) but I was >> not sure it was the right choice instead of the (apparently) more appealing >> ConcurrentUpdateSolrClient. >> >> As far as I understood, ConcurrentUpdateSolrClient is rooted with older >> versions of solr, may be older than the cloud version. >> Because of ConcurrentUpdateSolrClient constructors signature, they don't >> accept a zookeeper client or host:port as parameter. >> >> On the other hand, well, I'm not sure that a concurrent client does a job >> better than the standard CloudSolrServer. > > The concurrent client has one glaring flaw: It puts all update requests > into background threads, so any exceptions thrown by those requests are > logged and ignored. When you send an add or delete request, the client > returns immediately to your program and indicates success (by not > throwing an exception) ... even if the server you're talking to is > completely offline. > > In a bulk insert situation, you might not care about error handling, but > most people DO care about it. > > For most situations, you will want to use HttpSolrClient or > CloudSolrClient, depending on whether the target is running SolrCloud. > > Thanks, > Shawn >
