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, that's fine, just that infinity isn't reasonable and will eventually bite people :-) Will raise a JIRA.. On 5 Aug 2014 15:19, "Mark Miller" <[email protected]> wrote:
> 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 distributed system requires timeouts for proper > long term “chugging along”. > > -- > Mark Miller > about.me/markrmiller > > On August 5, 2014 at 7:46:36 AM, Ramkumar R. Aiyengar ( > [email protected]) wrote: > > 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 doesn't seem desirable. These are all configurable, we could > set some default (60s for conn, 600s for socket?), let people know and have > them up the limits if they really need it.. > > Thoughts? > >
