Thank you for your reply. Regards Reej
On Fri, 2 Jul 2021 at 10:58 PM, Vincenzo D'Amore <v.dam...@gmail.com> wrote: > 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 > -- *Thanks,* *Reej*
