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
