Hi Alessandro, 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. Best, Vincenzo On Thu, Nov 5, 2015 at 12:30 PM, Alessandro Benedetti <abenede...@apache.org > wrote: > Hi guys, > I was taking a look to the implementation details to understand how Solr > requests are written by SolrJ APIs. > The interesting classes are : > > *org.apache.solr.client.solrj.request.RequestWriter* > > *org.apache.solr.client.solrj.impl.BinaryRequestWriter* ( wrong package ? ) > > I discovered that : > > *CloudSolrClient *- is using the javabin format ( *BinaryRequestWriter*) > *HttpSolrClient *and* LBHttpSolrClient* - are using the *RequestWriter* ( > which writes xml) > > In consequence the ConcurrentUpdateSolrClient is using the xml > ResponseWriter as well. > > Is there any reason in this ? > I did know that the javabin format is the most efficient for Solr > requests. > Why the xml RequestWriter is still used as default with those SolrClients ? > > Cheers > > -- > -------------------------- > > Benedetti Alessandro > Visiting card : http://about.me/alessandro_benedetti > > "Tyger, tyger burning bright > In the forests of the night, > What immortal hand or eye > Could frame thy fearful symmetry?" > > William Blake - Songs of Experience -1794 England > -- Vincenzo D'Amore email: v.dam...@gmail.com skype: free.dev mobile: +39 349 8513251
