lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ramkumar Aiyengar (JIRA)" <>
Subject [jira] [Commented] (SOLR-6324) Set finite default timeouts for select and update
Date Thu, 27 Nov 2014 10:42:13 GMT


Ramkumar Aiyengar commented on SOLR-6324:

People shouldn't use optimize anyway, I wouldn't worry so much about breaking them and them
having to change defaults if they really want to do it.

My preference is for keeping this number as low as sensible, I would rather have them fail
early than wait for the first time a machine crashes and they see through the consequences
of a long read timeout -- not many people test for that. But that said, if there are other
things which genuinely take more than this time, we can certainly consider increasing this
(and contemplate if some kind of an asynchronous API or optimization suits better than making
a client wait at one time for more than 10 mins!)

> Set finite default timeouts for select and update
> -------------------------------------------------
>                 Key: SOLR-6324
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: search, update
>            Reporter: Ramkumar Aiyengar
>            Assignee: Mark Miller
>            Priority: Minor
>             Fix For: 5.0, Trunk
> Currently {{HttpShardHandlerFactory}} and {{UpdateShardHandler}} default to infinite
timeouts for socket connection and read. This can lead to undesirable behaviour, for example,
if a machine crashes, then searches in progress will wait forever for a result to come back
and end up using threads which will only get terminated at shutdown.
> We should have some finite default, however conservative it might be. These parameters
are already configurable, so for expert uses, they can be increased if necessary anyway.
> Will attach a patch to set connection timeout to 60s and read timeout to 600s, but I
am not too concerned about the actual value as long as there is one.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message