jvanneman commented on PR #3891: URL: https://github.com/apache/solr/pull/3891#issuecomment-3725805435
> I do have a slight worry that maybe an errant request that takes way too long for reasons specific to the request @dsmiley I think as long as folks are using `timeAllowed` and set the order of timeouts as socketTimeout > timeAllowed, then this will only trigger when processing time + in flight time + jetty queue time is > socketTimeout. In practice what i think would usually happen is that a request would be stuck in the jetty queue for a long time before it's processed and the cumulative processing time + queue time would trigger socketTimeout before timeAllowed is up. In which case I think it's not a bad idea to mark the server as unresponsive because it means there's enough requests queued to degrade performance. One edge case to this might be [two phase requests like grouping](https://github.com/apache/solr/blob/c011ac05859b4efe3913b0c6bf8ce73a01f28daf/solr/core/src/java/org/apache/solr/search/grouping/distributed/requestfactory/TopGroupsShardRequestFactory.java#L90). It could plausibly make sense to have socketTime < timeAllowed in which the socketTimeout servces as the upper bound for phase 1 and leaves the request some room to complete phase 2. This is more likely to results in the scenario you describe. It might be worth a different mechanism to restrict first phase time in those types of requests though, I don't think setting socketTimeout to accomplish that makes sense. Updated the PR based on your suggestions! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
