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* >> >
