You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@solr.apache.org by Reej Nayagam <re...@gmail.com> on 2021/06/28 03:53:58 UTC
HTTPSolrClient
Hi Team,
We recently upgraded to solr8.8.2
We have replaced all our httpsolrserver connections to httpsolrclient and
haven't explicitly closed the connections.
Even in solr4 we haven't closed the connections. But now our main
application has become too slow and it was said there is TIME_WAIT from the
search server.
Can you advise is it necessary to close each httpsolrclient connection in
finally clause or does jetty takes care of the connectons timeout.
*Thanks,*
*Reej*
Re: HTTPSolrClient - help required
Posted by Vincenzo D'Amore <v....@gmail.com>.
have you tried to use the httpsolrclient as singletons?
Create them only once and reuse. Not sure but I think it’s a best practice.
Ciao,
Vincenzo
> On 29 Jun 2021, at 03:59, Reej Nayagam <re...@gmail.com> wrote:
>
> Hi Team,
> Any advise is highly appreciated.
> Do we need to use a singleton connection of a connection pool. Please kindly advise
>
> Thanks
> Reej
>
> Sent from my iPhone
>
> Begin forwarded message:
>
>> From: Reej Nayagam <re...@gmail.com>
>> Date: 28 June 2021 at 11:53:58 AM SGT
>> To: Solr <us...@solr.apache.org>, solr-user Lucene <so...@lucene.apache.org>
>> Subject: HTTPSolrClient
>>
>>
>> Hi Team,
>> We recently upgraded to solr8.8.2
>> We have replaced all our httpsolrserver connections to httpsolrclient and haven't explicitly closed the connections.
>> Even in solr4 we haven't closed the connections. But now our main application has become too slow and it was said there is TIME_WAIT from the search server.
>> Can you advise is it necessary to close each httpsolrclient connection in finally clause or does jetty takes care of the connectons timeout.
>>
>> Thanks,
>> Reej
RE: HTTPSolrClient - help required
Posted by Srinivas Kashyap <sr...@bamboorose.com.INVALID>.
Yes,
Update your solrJ class library in your application and you can invoke like below:
1) Your singleton implementation should return you the client till base url( http://xxx.xxx.x.xxx:*8983*/solr/)
2) Once you get client object, you might be doing client.query() or client.commit(), just pass the corename as first parameter
Thanks and Regards,
Srinivas Kashyap
-----Original Message-----
From: Reej Nayagam <re...@gmail.com>
Sent: 29 June 2021 15:47
To: Solr <us...@solr.apache.org>
Cc: solr-user Lucene <so...@lucene.apache.org>
Subject: Re: HTTPSolrClient - help required
Hi
Thanks for the reply.
I'm trying to create a singleton, but my worry is my base url changes based on the leader.
so we have 14 repositories, and if we need to trigger indexing for 1 core, then url will be http://xxx.xxx.x.xxx:*8983*/solr/watchlist, for another core it'll be http://xxx.xxx.x.xxx:*5983*/solr/message
so in this scenario is it possible to go with Singleton.
Kindly advise
*Thanks,*
*Reej*
On Tue, Jun 29, 2021 at 5:36 PM Srinivas Kashyap <sr...@bamboorose.com.invalid> wrote:
> Hi Reej,
>
> Yes, create a singleton class of HttpSolrClient for entire scope of
> application. As mentioned by you, if you don’t close the connection,
> thread will be in hung state and affects the performance. I too faced
> this in my implementation.
>
> Thanks and Regards,
> Srinivas Kashyap
>
> Leading Retail Platform to discover, develop, and deliver products @
> consumer speed.
>
> -----Original Message-----
> From: Reej Nayagam <re...@gmail.com>
> Sent: 29 June 2021 07:29
> To: Solr <us...@solr.apache.org>; solr-user Lucene <
> solr-user@lucene.apache.org>
> Subject: Fwd: HTTPSolrClient - help required
>
> Hi Team,
> Any advise is highly appreciated.
> Do we need to use a singleton connection of a connection pool. Please
> kindly advise
>
> Thanks
> Reej
>
> Sent from my iPhone
>
> Begin forwarded message:
>
> > From: Reej Nayagam <re...@gmail.com>
> > Date: 28 June 2021 at 11:53:58 AM SGT
> > To: Solr <us...@solr.apache.org>, solr-user Lucene <
> solr-user@lucene.apache.org>
> > Subject: HTTPSolrClient
> >
> >
> > Hi Team,
> > We recently upgraded to solr8.8.2
> > We have replaced all our httpsolrserver connections to
> > httpsolrclient
> and haven't explicitly closed the connections.
> > Even in solr4 we haven't closed the connections. But now our main
> application has become too slow and it was said there is TIME_WAIT
> from the search server.
> > Can you advise is it necessary to close each httpsolrclient
> > connection
> in finally clause or does jetty takes care of the connectons timeout.
> >
> > Thanks,
> > Reej
> ________________________________
> DISCLAIMER:
> E-mails and attachments from Bamboo Rose, LLC are confidential.
> If you are not the intended recipient, please notify the sender
> immediately by replying to the e-mail, and then delete it without
> making copies or using it in any way.
> No representation is made that this email or any attachments are free
> of viruses. Virus scanning is recommended and is the responsibility of
> the recipient.
>
> Disclaimer
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and
> others authorized to receive it. If you are not the recipient, you are
> hereby notified that any disclosure, copying, distribution or taking
> action in relation of the contents of this information is strictly
> prohibited and may be unlawful.
>
> This email has been scanned for viruses and malware, and may have been
> automatically archived by Mimecast Ltd, an innovator in Software as a
> Service (SaaS) for business. Providing a safer and more useful place
> for your human generated data. Specializing in; Security, archiving
> and compliance. To find out more visit the Mimecast website.
>
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
Re: HTTPSolrClient - help required
Posted by Reej Nayagam <re...@gmail.com>.
Hi Srinivas,
Thanks for the reply.
Im solr setup has multiple repositories in a cluster setup, and we are
indexing calling the leader url
*HTTPSolrClient solrclient = new HTTPSolrcient.Builder(url).build*
we neve close this. For each indexing we just call the above and open
connection.
I'm trying to create a singleton, but my worry is, my base url changes
based on the leader.
so we have 10 +repositories, and if we need to trigger indexing for 1 core,
then url will be http://xxx.xxx.x.xxx:*8983*/solr/watchlist, for another
core it'll be http://xxx.xxx.x.xxx:*5983*/solr/message
so in this scenario is it possible to go with Singleton.
Kindly advise
I found below reference online, but I dont think I can go with this
approach,
https://gitedu.hesge.ch/ricardo.nunesdeo/tb_foodspector/-/commit/f4219ee26777d7a9168df03effd9ce3afbab9c80
If any of you have faced similar situation kindly help
*Thanks,*
*Reej*
On Tue, Jun 29, 2021 at 6:17 PM Reej Nayagam <re...@gmail.com> wrote:
> Hi
> Thanks for the reply.
> I'm trying to create a singleton, but my worry is my base url changes
> based on the leader.
> so we have 14 repositories, and if we need to trigger indexing for 1 core,
> then url will be http://xxx.xxx.x.xxx:*8983*/solr/watchlist, for another
> core it'll be http://xxx.xxx.x.xxx:*5983*/solr/message
> so in this scenario is it possible to go with Singleton.
> Kindly advise
>
>
> *Thanks,*
> *Reej*
>
>
> On Tue, Jun 29, 2021 at 5:36 PM Srinivas Kashyap
> <sr...@bamboorose.com.invalid> wrote:
>
>> Hi Reej,
>>
>> Yes, create a singleton class of HttpSolrClient for entire scope of
>> application. As mentioned by you, if you don’t close the connection, thread
>> will be in hung state and affects the performance. I too faced this in my
>> implementation.
>>
>> Thanks and Regards,
>> Srinivas Kashyap
>>
>> Leading Retail Platform to discover, develop, and deliver products @
>> consumer speed.
>>
>> -----Original Message-----
>> From: Reej Nayagam <re...@gmail.com>
>> Sent: 29 June 2021 07:29
>> To: Solr <us...@solr.apache.org>; solr-user Lucene <
>> solr-user@lucene.apache.org>
>> Subject: Fwd: HTTPSolrClient - help required
>>
>> Hi Team,
>> Any advise is highly appreciated.
>> Do we need to use a singleton connection of a connection pool. Please
>> kindly advise
>>
>> Thanks
>> Reej
>>
>> Sent from my iPhone
>>
>> Begin forwarded message:
>>
>> > From: Reej Nayagam <re...@gmail.com>
>> > Date: 28 June 2021 at 11:53:58 AM SGT
>> > To: Solr <us...@solr.apache.org>, solr-user Lucene <
>> solr-user@lucene.apache.org>
>> > Subject: HTTPSolrClient
>> >
>> >
>> > Hi Team,
>> > We recently upgraded to solr8.8.2
>> > We have replaced all our httpsolrserver connections to httpsolrclient
>> and haven't explicitly closed the connections.
>> > Even in solr4 we haven't closed the connections. But now our main
>> application has become too slow and it was said there is TIME_WAIT from the
>> search server.
>> > Can you advise is it necessary to close each httpsolrclient connection
>> in finally clause or does jetty takes care of the connectons timeout.
>> >
>> > Thanks,
>> > Reej
>> ________________________________
>> DISCLAIMER:
>> E-mails and attachments from Bamboo Rose, LLC are confidential.
>> If you are not the intended recipient, please notify the sender
>> immediately by replying to the e-mail, and then delete it without making
>> copies or using it in any way.
>> No representation is made that this email or any attachments are free of
>> viruses. Virus scanning is recommended and is the responsibility of the
>> recipient.
>>
>> Disclaimer
>>
>> The information contained in this communication from the sender is
>> confidential. It is intended solely for use by the recipient and others
>> authorized to receive it. If you are not the recipient, you are hereby
>> notified that any disclosure, copying, distribution or taking action in
>> relation of the contents of this information is strictly prohibited and may
>> be unlawful.
>>
>> This email has been scanned for viruses and malware, and may have been
>> automatically archived by Mimecast Ltd, an innovator in Software as a
>> Service (SaaS) for business. Providing a safer and more useful place for
>> your human generated data. Specializing in; Security, archiving and
>> compliance. To find out more visit the Mimecast website.
>>
>
Re: HTTPSolrClient - help required [Singleton Recommended?]
Posted by Reej Nayagam <re...@gmail.com>.
Thanks a lot Shawn.
Regards
Reej
On Mon, 5 Jul 2021 at 1:27 PM, Shawn Heisey <ap...@elyograg.org> wrote:
> On 7/4/2021 8:55 PM, Reej Nayagam wrote:
> > Please find the versions as below
> > Solr core - 8.8.2
> > Solrj - 8.8.2
> > Zookeeper - 3.6.3
> > Zookeeper jute - 3.6.3
> >
> > Kindly do share any code samples if you have them.
>
> I built some code and pasted it here:
>
> https://apaste.info/fI0a
>
> In my example, this class is called TestSolr, and the method I've built
> is static. So to use it in another class, you would do something like
> this:
>
> SolrClient client = TestSolr.getSolrClient();
>
> The synchronization on the method ensures that it all works properly in
> multi-threaded code. If you assign the parts of the ZK ensemble
> somewhere else, you might need to think about proper synchronization for
> that too.
>
> I hope this illustrates what Vincenzo and I were talking about.
>
> Thanks,
> Shawn
>
--
*Thanks,*
*Reej*
Re: HTTPSolrClient - help required [Singleton Recommended?]
Posted by Shawn Heisey <ap...@elyograg.org>.
On 7/4/2021 8:55 PM, Reej Nayagam wrote:
> Please find the versions as below
> Solr core - 8.8.2
> Solrj - 8.8.2
> Zookeeper - 3.6.3
> Zookeeper jute - 3.6.3
>
> Kindly do share any code samples if you have them.
I built some code and pasted it here:
https://apaste.info/fI0a
In my example, this class is called TestSolr, and the method I've built
is static. So to use it in another class, you would do something like this:
SolrClient client = TestSolr.getSolrClient();
The synchronization on the method ensures that it all works properly in
multi-threaded code. If you assign the parts of the ZK ensemble
somewhere else, you might need to think about proper synchronization for
that too.
I hope this illustrates what Vincenzo and I were talking about.
Thanks,
Shawn
Re: HTTPSolrClient - help required [Singleton Recommended?]
Posted by Reej Nayagam <re...@gmail.com>.
Hi Shawn,
Please find the versions as below
Solr core - 8.8.2
Solrj - 8.8.2
Zookeeper - 3.6.3
Zookeeper jute - 3.6.3
Kindly do share any code samples if you have them.
Thanks & Regards
Reej
On Fri, 2 Jul 2021 at 9:05 AM, Shawn Heisey <ap...@elyograg.org> wrote:
> On 7/1/2021 6:36 PM, Reej M 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.
>
> All SolrClient implementations, including CloudSolrClient and
> HttpSolrClient, are completely threadsafe. You can use them in many
> threads without causing any problems. If usage will be VERY heavy, you
> might need to fiddle with the object a little bit when you create it to
> allow more threads. Recent versions of SolrJ have sane defaults, but
> some of the older ones only run two threads at once if you don't change
> it. Things won't break with defaults on one of those older versions,
> you just might have performance issues. If necessary, I can fire up my
> IDE and figure out some code for you, you'll need to tell me what SolrJ
> version you have.
>
> The general recommendation is to create one client object at program
> startup and then use that object everywhere in the program. If I
> understand the Singleton paradigm correctly, something similar is what
> we recommend.
>
> You can either access the client object via a public static variable or
> build a public static synchronized method in a class that returns the
> client object, creating it if it doesn't already exist. Using public
> variables in a class is generally frowned on by experienced Java
> developers, I would go with the static method.
>
> Thanks,
> Shawn
>
--
*Thanks,*
*Reej*
Re: HTTPSolrClient - help required [Singleton Recommended?]
Posted by Shawn Heisey <ap...@elyograg.org>.
On 7/1/2021 6:36 PM, Reej M 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.
All SolrClient implementations, including CloudSolrClient and
HttpSolrClient, are completely threadsafe. You can use them in many
threads without causing any problems. If usage will be VERY heavy, you
might need to fiddle with the object a little bit when you create it to
allow more threads. Recent versions of SolrJ have sane defaults, but
some of the older ones only run two threads at once if you don't change
it. Things won't break with defaults on one of those older versions,
you just might have performance issues. If necessary, I can fire up my
IDE and figure out some code for you, you'll need to tell me what SolrJ
version you have.
The general recommendation is to create one client object at program
startup and then use that object everywhere in the program. If I
understand the Singleton paradigm correctly, something similar is what
we recommend.
You can either access the client object via a public static variable or
build a public static synchronized method in a class that returns the
client object, creating it if it doesn't already exist. Using public
variables in a class is generally frowned on by experienced Java
developers, I would go with the static method.
Thanks,
Shawn
Re: HTTPSolrClient - help required [Singleton Recommended?]
Posted by Reej Nayagam <re...@gmail.com>.
Thank you for your reply.
Regards
Reej
On Fri, 2 Jul 2021 at 10:58 PM, Vincenzo D'Amore <v....@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 <re...@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 <re...@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 <wu...@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 <re...@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 <ap...@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*
Re: HTTPSolrClient - help required [Singleton Recommended?]
Posted by Vincenzo D'Amore <v....@gmail.com>.
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 <re...@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 <re...@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 <wu...@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 <re...@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....@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 <ap...@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
Re: HTTPSolrClient - help required [Singleton Recommended?]
Posted by Reej M <re...@gmail.com>.
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 <re...@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 <wu...@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 <re...@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....@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 <ap...@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*
>>
>
Re: HTTPSolrClient - help required
Posted by Reej M <re...@gmail.com>.
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 <wu...@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 <re...@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....@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 <ap...@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*
>
Re: HTTPSolrClient - help required
Posted by Walter Underwood <wu...@wunderwood.org>.
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 <re...@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....@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 <ap...@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*
Re: HTTPSolrClient - help required
Posted by Reej Nayagam <re...@gmail.com>.
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....@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 <ap...@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*
Re: HTTPSolrClient - help required
Posted by Vincenzo D'Amore <v....@gmail.com>.
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 <ap...@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
Re: HTTPSolrClient - help required
Posted by Shawn Heisey <ap...@elyograg.org>.
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
Re: HTTPSolrClient - help required
Posted by Reej Nayagam <re...@gmail.com>.
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.
Thanks
Sent from my iPhone
> On 29 Jun 2021, at 8:01 PM, Vincenzo D'Amore <v....@gmail.com> wrote:
>
> I mean, why are you looking for the leader?
>
>> On Tue, Jun 29, 2021 at 1:58 PM Vincenzo D'Amore <v....@gmail.com> wrote:
>>
>> not sure I got your answer... are you using solrcloud?
>>
>>> On Tue, Jun 29, 2021 at 12:18 PM Reej Nayagam <re...@gmail.com> wrote:
>>>
>>> Hi
>>> Thanks for the reply.
>>> I'm trying to create a singleton, but my worry is my base url changes
>>> based
>>> on the leader.
>>> so we have 14 repositories, and if we need to trigger indexing for 1 core,
>>> then url will be http://xxx.xxx.x.xxx:*8983*/solr/watchlist, for another
>>> core it'll be http://xxx.xxx.x.xxx:*5983*/solr/message
>>> so in this scenario is it possible to go with Singleton.
>>> Kindly advise
>>>
>>>
>>> *Thanks,*
>>> *Reej*
>>>
>>>
>>> On Tue, Jun 29, 2021 at 5:36 PM Srinivas Kashyap
>>> <sr...@bamboorose.com.invalid> wrote:
>>>
>>>> Hi Reej,
>>>>
>>>> Yes, create a singleton class of HttpSolrClient for entire scope of
>>>> application. As mentioned by you, if you don’t close the connection,
>>> thread
>>>> will be in hung state and affects the performance. I too faced this in
>>> my
>>>> implementation.
>>>>
>>>> Thanks and Regards,
>>>> Srinivas Kashyap
>>>>
>>>> Leading Retail Platform to discover, develop, and deliver products @
>>>> consumer speed.
>>>>
>>>> -----Original Message-----
>>>> From: Reej Nayagam <re...@gmail.com>
>>>> Sent: 29 June 2021 07:29
>>>> To: Solr <us...@solr.apache.org>; solr-user Lucene <
>>>> solr-user@lucene.apache.org>
>>>> Subject: Fwd: HTTPSolrClient - help required
>>>>
>>>> Hi Team,
>>>> Any advise is highly appreciated.
>>>> Do we need to use a singleton connection of a connection pool. Please
>>>> kindly advise
>>>>
>>>> Thanks
>>>> Reej
>>>>
>>>> Sent from my iPhone
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Reej Nayagam <re...@gmail.com>
>>>>> Date: 28 June 2021 at 11:53:58 AM SGT
>>>>> To: Solr <us...@solr.apache.org>, solr-user Lucene <
>>>> solr-user@lucene.apache.org>
>>>>> Subject: HTTPSolrClient
>>>>>
>>>>>
>>>>> Hi Team,
>>>>> We recently upgraded to solr8.8.2
>>>>> We have replaced all our httpsolrserver connections to httpsolrclient
>>>> and haven't explicitly closed the connections.
>>>>> Even in solr4 we haven't closed the connections. But now our main
>>>> application has become too slow and it was said there is TIME_WAIT from
>>> the
>>>> search server.
>>>>> Can you advise is it necessary to close each httpsolrclient connection
>>>> in finally clause or does jetty takes care of the connectons timeout.
>>>>>
>>>>> Thanks,
>>>>> Reej
>>>> ________________________________
>>>> DISCLAIMER:
>>>> E-mails and attachments from Bamboo Rose, LLC are confidential.
>>>> If you are not the intended recipient, please notify the sender
>>>> immediately by replying to the e-mail, and then delete it without making
>>>> copies or using it in any way.
>>>> No representation is made that this email or any attachments are free of
>>>> viruses. Virus scanning is recommended and is the responsibility of the
>>>> recipient.
>>>>
>>>> Disclaimer
>>>>
>>>> The information contained in this communication from the sender is
>>>> confidential. It is intended solely for use by the recipient and others
>>>> authorized to receive it. If you are not the recipient, you are hereby
>>>> notified that any disclosure, copying, distribution or taking action in
>>>> relation of the contents of this information is strictly prohibited and
>>> may
>>>> be unlawful.
>>>>
>>>> This email has been scanned for viruses and malware, and may have been
>>>> automatically archived by Mimecast Ltd, an innovator in Software as a
>>>> Service (SaaS) for business. Providing a safer and more useful place for
>>>> your human generated data. Specializing in; Security, archiving and
>>>> compliance. To find out more visit the Mimecast website.
>>>>
>>>
>>
>>
>> --
>> Vincenzo D'Amore
>>
>>
>
> --
> Vincenzo D'Amore
Re: HTTPSolrClient - help required
Posted by Vincenzo D'Amore <v....@gmail.com>.
I mean, why are you looking for the leader?
On Tue, Jun 29, 2021 at 1:58 PM Vincenzo D'Amore <v....@gmail.com> wrote:
> not sure I got your answer... are you using solrcloud?
>
> On Tue, Jun 29, 2021 at 12:18 PM Reej Nayagam <re...@gmail.com> wrote:
>
>> Hi
>> Thanks for the reply.
>> I'm trying to create a singleton, but my worry is my base url changes
>> based
>> on the leader.
>> so we have 14 repositories, and if we need to trigger indexing for 1 core,
>> then url will be http://xxx.xxx.x.xxx:*8983*/solr/watchlist, for another
>> core it'll be http://xxx.xxx.x.xxx:*5983*/solr/message
>> so in this scenario is it possible to go with Singleton.
>> Kindly advise
>>
>>
>> *Thanks,*
>> *Reej*
>>
>>
>> On Tue, Jun 29, 2021 at 5:36 PM Srinivas Kashyap
>> <sr...@bamboorose.com.invalid> wrote:
>>
>> > Hi Reej,
>> >
>> > Yes, create a singleton class of HttpSolrClient for entire scope of
>> > application. As mentioned by you, if you don’t close the connection,
>> thread
>> > will be in hung state and affects the performance. I too faced this in
>> my
>> > implementation.
>> >
>> > Thanks and Regards,
>> > Srinivas Kashyap
>> >
>> > Leading Retail Platform to discover, develop, and deliver products @
>> > consumer speed.
>> >
>> > -----Original Message-----
>> > From: Reej Nayagam <re...@gmail.com>
>> > Sent: 29 June 2021 07:29
>> > To: Solr <us...@solr.apache.org>; solr-user Lucene <
>> > solr-user@lucene.apache.org>
>> > Subject: Fwd: HTTPSolrClient - help required
>> >
>> > Hi Team,
>> > Any advise is highly appreciated.
>> > Do we need to use a singleton connection of a connection pool. Please
>> > kindly advise
>> >
>> > Thanks
>> > Reej
>> >
>> > Sent from my iPhone
>> >
>> > Begin forwarded message:
>> >
>> > > From: Reej Nayagam <re...@gmail.com>
>> > > Date: 28 June 2021 at 11:53:58 AM SGT
>> > > To: Solr <us...@solr.apache.org>, solr-user Lucene <
>> > solr-user@lucene.apache.org>
>> > > Subject: HTTPSolrClient
>> > >
>> > >
>> > > Hi Team,
>> > > We recently upgraded to solr8.8.2
>> > > We have replaced all our httpsolrserver connections to httpsolrclient
>> > and haven't explicitly closed the connections.
>> > > Even in solr4 we haven't closed the connections. But now our main
>> > application has become too slow and it was said there is TIME_WAIT from
>> the
>> > search server.
>> > > Can you advise is it necessary to close each httpsolrclient connection
>> > in finally clause or does jetty takes care of the connectons timeout.
>> > >
>> > > Thanks,
>> > > Reej
>> > ________________________________
>> > DISCLAIMER:
>> > E-mails and attachments from Bamboo Rose, LLC are confidential.
>> > If you are not the intended recipient, please notify the sender
>> > immediately by replying to the e-mail, and then delete it without making
>> > copies or using it in any way.
>> > No representation is made that this email or any attachments are free of
>> > viruses. Virus scanning is recommended and is the responsibility of the
>> > recipient.
>> >
>> > Disclaimer
>> >
>> > The information contained in this communication from the sender is
>> > confidential. It is intended solely for use by the recipient and others
>> > authorized to receive it. If you are not the recipient, you are hereby
>> > notified that any disclosure, copying, distribution or taking action in
>> > relation of the contents of this information is strictly prohibited and
>> may
>> > be unlawful.
>> >
>> > This email has been scanned for viruses and malware, and may have been
>> > automatically archived by Mimecast Ltd, an innovator in Software as a
>> > Service (SaaS) for business. Providing a safer and more useful place for
>> > your human generated data. Specializing in; Security, archiving and
>> > compliance. To find out more visit the Mimecast website.
>> >
>>
>
>
> --
> Vincenzo D'Amore
>
>
--
Vincenzo D'Amore
Re: HTTPSolrClient - help required
Posted by Vincenzo D'Amore <v....@gmail.com>.
not sure I got your answer... are you using solrcloud?
On Tue, Jun 29, 2021 at 12:18 PM Reej Nayagam <re...@gmail.com> wrote:
> Hi
> Thanks for the reply.
> I'm trying to create a singleton, but my worry is my base url changes based
> on the leader.
> so we have 14 repositories, and if we need to trigger indexing for 1 core,
> then url will be http://xxx.xxx.x.xxx:*8983*/solr/watchlist, for another
> core it'll be http://xxx.xxx.x.xxx:*5983*/solr/message
> so in this scenario is it possible to go with Singleton.
> Kindly advise
>
>
> *Thanks,*
> *Reej*
>
>
> On Tue, Jun 29, 2021 at 5:36 PM Srinivas Kashyap
> <sr...@bamboorose.com.invalid> wrote:
>
> > Hi Reej,
> >
> > Yes, create a singleton class of HttpSolrClient for entire scope of
> > application. As mentioned by you, if you don’t close the connection,
> thread
> > will be in hung state and affects the performance. I too faced this in my
> > implementation.
> >
> > Thanks and Regards,
> > Srinivas Kashyap
> >
> > Leading Retail Platform to discover, develop, and deliver products @
> > consumer speed.
> >
> > -----Original Message-----
> > From: Reej Nayagam <re...@gmail.com>
> > Sent: 29 June 2021 07:29
> > To: Solr <us...@solr.apache.org>; solr-user Lucene <
> > solr-user@lucene.apache.org>
> > Subject: Fwd: HTTPSolrClient - help required
> >
> > Hi Team,
> > Any advise is highly appreciated.
> > Do we need to use a singleton connection of a connection pool. Please
> > kindly advise
> >
> > Thanks
> > Reej
> >
> > Sent from my iPhone
> >
> > Begin forwarded message:
> >
> > > From: Reej Nayagam <re...@gmail.com>
> > > Date: 28 June 2021 at 11:53:58 AM SGT
> > > To: Solr <us...@solr.apache.org>, solr-user Lucene <
> > solr-user@lucene.apache.org>
> > > Subject: HTTPSolrClient
> > >
> > >
> > > Hi Team,
> > > We recently upgraded to solr8.8.2
> > > We have replaced all our httpsolrserver connections to httpsolrclient
> > and haven't explicitly closed the connections.
> > > Even in solr4 we haven't closed the connections. But now our main
> > application has become too slow and it was said there is TIME_WAIT from
> the
> > search server.
> > > Can you advise is it necessary to close each httpsolrclient connection
> > in finally clause or does jetty takes care of the connectons timeout.
> > >
> > > Thanks,
> > > Reej
> > ________________________________
> > DISCLAIMER:
> > E-mails and attachments from Bamboo Rose, LLC are confidential.
> > If you are not the intended recipient, please notify the sender
> > immediately by replying to the e-mail, and then delete it without making
> > copies or using it in any way.
> > No representation is made that this email or any attachments are free of
> > viruses. Virus scanning is recommended and is the responsibility of the
> > recipient.
> >
> > Disclaimer
> >
> > The information contained in this communication from the sender is
> > confidential. It is intended solely for use by the recipient and others
> > authorized to receive it. If you are not the recipient, you are hereby
> > notified that any disclosure, copying, distribution or taking action in
> > relation of the contents of this information is strictly prohibited and
> may
> > be unlawful.
> >
> > This email has been scanned for viruses and malware, and may have been
> > automatically archived by Mimecast Ltd, an innovator in Software as a
> > Service (SaaS) for business. Providing a safer and more useful place for
> > your human generated data. Specializing in; Security, archiving and
> > compliance. To find out more visit the Mimecast website.
> >
>
--
Vincenzo D'Amore
Re: HTTPSolrClient - help required
Posted by Reej Nayagam <re...@gmail.com>.
Hi
Thanks for the reply.
I'm trying to create a singleton, but my worry is my base url changes based
on the leader.
so we have 14 repositories, and if we need to trigger indexing for 1 core,
then url will be http://xxx.xxx.x.xxx:*8983*/solr/watchlist, for another
core it'll be http://xxx.xxx.x.xxx:*5983*/solr/message
so in this scenario is it possible to go with Singleton.
Kindly advise
*Thanks,*
*Reej*
On Tue, Jun 29, 2021 at 5:36 PM Srinivas Kashyap
<sr...@bamboorose.com.invalid> wrote:
> Hi Reej,
>
> Yes, create a singleton class of HttpSolrClient for entire scope of
> application. As mentioned by you, if you don’t close the connection, thread
> will be in hung state and affects the performance. I too faced this in my
> implementation.
>
> Thanks and Regards,
> Srinivas Kashyap
>
> Leading Retail Platform to discover, develop, and deliver products @
> consumer speed.
>
> -----Original Message-----
> From: Reej Nayagam <re...@gmail.com>
> Sent: 29 June 2021 07:29
> To: Solr <us...@solr.apache.org>; solr-user Lucene <
> solr-user@lucene.apache.org>
> Subject: Fwd: HTTPSolrClient - help required
>
> Hi Team,
> Any advise is highly appreciated.
> Do we need to use a singleton connection of a connection pool. Please
> kindly advise
>
> Thanks
> Reej
>
> Sent from my iPhone
>
> Begin forwarded message:
>
> > From: Reej Nayagam <re...@gmail.com>
> > Date: 28 June 2021 at 11:53:58 AM SGT
> > To: Solr <us...@solr.apache.org>, solr-user Lucene <
> solr-user@lucene.apache.org>
> > Subject: HTTPSolrClient
> >
> >
> > Hi Team,
> > We recently upgraded to solr8.8.2
> > We have replaced all our httpsolrserver connections to httpsolrclient
> and haven't explicitly closed the connections.
> > Even in solr4 we haven't closed the connections. But now our main
> application has become too slow and it was said there is TIME_WAIT from the
> search server.
> > Can you advise is it necessary to close each httpsolrclient connection
> in finally clause or does jetty takes care of the connectons timeout.
> >
> > Thanks,
> > Reej
> ________________________________
> DISCLAIMER:
> E-mails and attachments from Bamboo Rose, LLC are confidential.
> If you are not the intended recipient, please notify the sender
> immediately by replying to the e-mail, and then delete it without making
> copies or using it in any way.
> No representation is made that this email or any attachments are free of
> viruses. Virus scanning is recommended and is the responsibility of the
> recipient.
>
> Disclaimer
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful.
>
> This email has been scanned for viruses and malware, and may have been
> automatically archived by Mimecast Ltd, an innovator in Software as a
> Service (SaaS) for business. Providing a safer and more useful place for
> your human generated data. Specializing in; Security, archiving and
> compliance. To find out more visit the Mimecast website.
>
RE: HTTPSolrClient - help required
Posted by Srinivas Kashyap <sr...@bamboorose.com.INVALID>.
Hi Reej,
Yes, create a singleton class of HttpSolrClient for entire scope of application. As mentioned by you, if you don’t close the connection, thread will be in hung state and affects the performance. I too faced this in my implementation.
Thanks and Regards,
Srinivas Kashyap
Leading Retail Platform to discover, develop, and deliver products @ consumer speed.
-----Original Message-----
From: Reej Nayagam <re...@gmail.com>
Sent: 29 June 2021 07:29
To: Solr <us...@solr.apache.org>; solr-user Lucene <so...@lucene.apache.org>
Subject: Fwd: HTTPSolrClient - help required
Hi Team,
Any advise is highly appreciated.
Do we need to use a singleton connection of a connection pool. Please kindly advise
Thanks
Reej
Sent from my iPhone
Begin forwarded message:
> From: Reej Nayagam <re...@gmail.com>
> Date: 28 June 2021 at 11:53:58 AM SGT
> To: Solr <us...@solr.apache.org>, solr-user Lucene <so...@lucene.apache.org>
> Subject: HTTPSolrClient
>
>
> Hi Team,
> We recently upgraded to solr8.8.2
> We have replaced all our httpsolrserver connections to httpsolrclient and haven't explicitly closed the connections.
> Even in solr4 we haven't closed the connections. But now our main application has become too slow and it was said there is TIME_WAIT from the search server.
> Can you advise is it necessary to close each httpsolrclient connection in finally clause or does jetty takes care of the connectons timeout.
>
> Thanks,
> Reej
________________________________
DISCLAIMER:
E-mails and attachments from Bamboo Rose, LLC are confidential.
If you are not the intended recipient, please notify the sender immediately by replying to the e-mail, and then delete it without making copies or using it in any way.
No representation is made that this email or any attachments are free of viruses. Virus scanning is recommended and is the responsibility of the recipient.
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
Fwd: HTTPSolrClient - help required
Posted by Reej Nayagam <re...@gmail.com>.
Hi Team,
Any advise is highly appreciated.
Do we need to use a singleton connection of a connection pool. Please kindly advise
Thanks
Reej
Sent from my iPhone
Begin forwarded message:
> From: Reej Nayagam <re...@gmail.com>
> Date: 28 June 2021 at 11:53:58 AM SGT
> To: Solr <us...@solr.apache.org>, solr-user Lucene <so...@lucene.apache.org>
> Subject: HTTPSolrClient
>
>
> Hi Team,
> We recently upgraded to solr8.8.2
> We have replaced all our httpsolrserver connections to httpsolrclient and haven't explicitly closed the connections.
> Even in solr4 we haven't closed the connections. But now our main application has become too slow and it was said there is TIME_WAIT from the search server.
> Can you advise is it necessary to close each httpsolrclient connection in finally clause or does jetty takes care of the connectons timeout.
>
> Thanks,
> Reej