rahulgoswami opened a new pull request #740: SOLR-12550 -
distribUpdateSoTimeout for configuring socket timeouts in solrcloud doesn't
take effect for updates.
URL: https://github.com/apache/lucene-solr/pull/740
# Description
Found this issue on Solr
stance.
> **/
> public void open() throws IOException {
> if(cache == null) {
> client = new HttpSolrClient.Builder(baseUrl).build();
> } else {
> client = cache.getHttpSolrClient(baseUrl);
> }
>
> I need to make this particular case configurable, so
class="HttpShardHandlerFactory">
> ${socketTimeout:60}
> ${connTimeout:6}
>
>
>
>
>
> --
> *From:* Gus Heck
> *Sent:* Sunday, May 5, 2019 1:35 PM
> *To:* dev
> *Subject:* Socket Timeouts
>
&g
both connectionTimeout and socketTimeout are declared in $SOLR_HOME/solr.xml
${socketTimeout:60}
${connTimeout:6}
From: Gus Heck
Sent: Sunday, May 5, 2019 1:35 PM
To: dev
Subject: Socket Timeouts
I'm working with a client that
ke this particular case configurable, so that I can get
> results from a very long running query, but I sense that there is a much
> wider problem in that we don't seem to have any organized plan for how
> socket timeouts are set/managed in the code.
>
> What thoughts have people had on this front?
>
> -Gus
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
ular case configurable, so that I can get results
from a very long running query, but I sense that there is a much wider
problem in that we don't seem to have any organized plan for how socket
timeouts are set/managed in the code.
What thoughts have people had on this front?
-Gus
--
http
I agree we need conservative defaults. I thought 10 mins is reasonable.
Obviously there will be longer requests, but that's where I would have
thought notice in CHANGES.txt would hopefully be good enough, you are
already looking at expert cases in such cases. If some other number is more
reasonable
Part of the issue is picking the right numbers I think. Some of our calls can
legit take a *long* time.
I think timeouts become a little more important with SolrCloud over ‘legacy
mode’ Solr.
Anyway, IMO, at some point we should introduce large defaults. It’s been on my
mind before. A good di
Currently HttpShardHandlerFactory and DUH2 set socket and connection
timeouts to unlimited by default. Should there be some finite default
instead? With the current defaults, a machine crash for example will lead
to requests in progress hang and occupy threads till the process is shut
down, which d
