solr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reej Nayagam <reej...@gmail.com>
Subject Re: HTTPSolrClient - help required [Singleton Recommended?]
Date Mon, 05 Jul 2021 02:51:01 GMT
Thank you for your reply.

Regards
Reej

On Fri, 2 Jul 2021 at 10:58 PM, Vincenzo D'Amore <v.damore@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 <reejmca@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 <reejmca@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 <wunder@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
> > >> wunder@wunderwood.org
> > >> http://observer.wunderwood.org/  (my blog)
> > >>
> > >>> On Jun 29, 2021, at 9:37 AM, Reej Nayagam <reejmca@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.damore@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 <apache@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*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message