the solrclients are thread safe so, yes, I recommend to use a single instance during all the life of your application (as said I prefer have an instance for each index/collection) If a network problem occurs, the client will manage to reconnect automatically to the server. But regarding the defaults I would specify connection and socket timeout during the cloudsolrclient creation (setConnectionTimeout, setSoTimeout). Pay attention, the timeouts are for both zookeeper and solr, just to be sure to handle the case if the network hangs .
On Fri, Jul 2, 2021 at 2:36 AM Reej M <reej...@gmail.com> wrote: > Hi Shawn / Team , > Need a suggestion on using the cloudsolrclient. > In our application, we have few cores which will be indexing every few > minutes (starting from 15 mins intervall and searching will also be done by > the users at the same time. Is it recommended to maintain a single > cloudsolrclient throughout the application, something like a singleton? Im > afraid if in a multi threaded env one thread shouldn’t hold the processing > until the other completes. Kindly advise. > > Thanks > Reej > > > On 30 Jun 2021, at 2:13 PM, Reej M <reej...@gmail.com> wrote: > > > > Oh ok Walter. > > For the moment, we too cannot update to cloudsolrclient, and we are > trying to find a way to resume the connections for now, and later work on > the code cleanup. Thanks > > > >> On 30 Jun 2021, at 12:49 AM, Walter Underwood <wun...@wunderwood.org> > wrote: > >> > >> CloudSolrClient is not an absolute requirement for a Solr Cloud > cluster. > >> > >> We use regular HTTPSolrClient sending all requests to the load balancer. > >> Actually, we use a separate load balancer for indexing, to keep the > monitoring > >> separate and to set different timeouts than for queries. > >> > >> This setup is simple and fast. With our biggest cluster, we index about > a > >> half million documents per minute. > >> > >> wunder > >> Walter Underwood > >> wun...@wunderwood.org > >> http://observer.wunderwood.org/ (my blog) > >> > >>> On Jun 29, 2021, at 9:37 AM, Reej Nayagam <reej...@gmail.com> wrote: > >>> > >>> Thanks Shawn & Vicenzo. Will check it out and change accordingly. > Thanks > >>> again Shawn for your clear explanation. > >>> > >>> Regards > >>> Reej > >>> > >>> > >>> On Tue, 29 Jun 2021 at 9:47 PM, Vincenzo D'Amore <v.dam...@gmail.com> > wrote: > >>> > >>>> Right, you should always use CloudSolrClient as a singleton. > >>>> To be honest I'm used to reuse a CloudSolrClient instance for each > >>>> collection/index. > >>>> > >>>> On Tue, Jun 29, 2021 at 3:12 PM Shawn Heisey <apa...@elyograg.org> > wrote: > >>>> > >>>>> On 6/29/2021 6:43 AM, Reej Nayagam wrote: > >>>>>> Hi Vincenzo Yes we are using cloud and initial solr version was > 4.10.4 > >>>>>> and we upgraded the jars alone to 8.8.2 now in the application side > >>>>>> connecting to solr Server to fix some vulnerability. As we have > >>>>>> upgraded the jars we changed httpsolrserver connection to > >>>>>> httpsolrclient and we guess there is some connection leak and wanted > >>>>>> to check if we need to close it or it is being handled internally. > >>>>>> Singleton not sure if I can use as the base URL changes depending on > >>>>>> the leader. > >>>>> > >>>>> If you're running SolrCloud, you should be using CloudSolrClient, not > >>>>> HttpSolrClient. The cloud client talks to zookeeper, so it is always > >>>>> aware of the cluster state -- it will be aware of down servers and > new > >>>>> servers, without recreating or reinitializing the client. And it > will > >>>>> be aware of changes instantly -- because that information is > coordinated > >>>>> in zookeeper. > >>>>> > >>>>> You can use a single client object for multiple collections. All of > the > >>>>> methods that execute requests should have a version where you can > pass > >>>>> it the name of the collection/core you want to operate on. For > >>>>> CloudSolrClient, you point it at all your ZK servers and it figures > out > >>>>> the Solr server URLs from the clusterstate in ZK. For > HttpSolrClient, > >>>>> you just leave the collection name off of the base URL -- > >>>>> "http://server.example.com:8983/solr"; is an example URL. > >>>>> > >>>>> As was mentioned, you should create a client during program startup > and > >>>>> then use it to handle all requests for the life of the program. It > >>>>> should manage connections and close them after receiving data, with > no > >>>>> coding needed from the developer (you). If you close a SolrClient > >>>>> object, it will not function after that. If you're having > connections > >>>>> stay open, then either you're running a Solr or SolrJ version with > bugs, > >>>>> or there is something wrong with your networking. > >>>>> > >>>>> It shouldn't be necessary to ever close a SolrClient object, unless > you > >>>>> create a new one every time your program talks to Solr. Which you > >>>>> shouldn't do. > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Shawn > >>>>> > >>>>> > >>>> > >>>> -- > >>>> Vincenzo D'Amore > >>>> > >>> -- > >>> *Thanks,* > >>> *Reej* > >> > > > > -- Vincenzo D'Amore
