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
