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