Re: [SolrJ Clients] RequestWriter VS BinaryRequestWriter
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 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 >
Re: [SolrJ Clients] RequestWriter VS BinaryRequestWriter
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
Re: [SolrJ Clients] RequestWriter VS BinaryRequestWriter
Hi Vincenzo, according to our discoveries I would say the CloudSolrClient to be the most efficient way to interact with a Solr Cloud cluster. ConcurrentUpdateSolrServer will be efficient for a single Solr instance, but using under the hood the XML Response Writer. Even if you prefer to use the javabin one ( which should be more efficient) . Cheers On 6 November 2015 at 14:15, Vincenzo D'Amore wrote: > 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 > -- -- 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
Re: [SolrJ Clients] RequestWriter VS BinaryRequestWriter
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 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
[SolrJ Clients] RequestWriter VS BinaryRequestWriter
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
