You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mark Miller (JIRA)" <ji...@apache.org> on 2019/04/10 17:58:00 UTC
[jira] [Comment Edited] (SOLR-13389) rectify discrepencies in
socket (and connect) timeout values used throughout the code and tests -
probably helping to reduce TimeoutExceptions in tests
[ https://issues.apache.org/jira/browse/SOLR-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814722#comment-16814722 ]
Mark Miller edited comment on SOLR-13389 at 4/10/19 5:57 PM:
-------------------------------------------------------------
Because no test should have a call that takes 10 minutes like is valid in the wild.
We raise all the timeouts so high in tests, tests start taking forever to fail when they fail or even to pass because failure is expected and takes forever.
I don't see any reason tests and production should have the same timeouts. Tests should have timeouts just large enough to work without false fails.
When our test timeouts are so long and loose, it simply hides slow and bad stuff and has for a long time.
I do agree that we should have way fewer places this stuff is set, but I also strongly believe there should be production and test defaults when it comes to timeouts. We don't want any 10 minute timeout in a test unless its a crazy test and a developer explicitly allows that.
was (Author: markrmiller@gmail.com):
Because no test should have a call that takes 10 minutes like it valid in the while.
We raise all the timeouts so high in tests, tests start taking forever to fail when they fail or even to pass because failure is expected and takes forever.
I don't see any reason tests and production should have the same timeouts. Tests should have timeouts just large enough to work without false fails.
When our test timeouts are so long and loose, it simply hides slow and bad stuff and has for a long time.
I do agree that we should have way fewer places this stuff is set, but I also strongly believe there should be production and test defaults when it comes to timeouts. We don't want any 10 minute timeout in a test unless its a crazy test and a developer explicitly allows that.
> rectify discrepencies in socket (and connect) timeout values used throughout the code and tests - probably helping to reduce TimeoutExceptions in tests
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-13389
> URL: https://issues.apache.org/jira/browse/SOLR-13389
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Hoss Man
> Priority: Major
>
> While looking into some jenkins test failures caused by distributed requests that timeout, i realized that the "socket timeout" aka "idle timeout" aka "SO_TIMEOUT" values used in various places in the code & sample configs can vary significantly, and in the case of *test* configs/code can differ from the default / production configs by an order of magnitude.
> I think we should consider rectifying some of the various places/ways that different values are sprinkled through out the code to reduce the number of (different) places we have magic constants. I believe a large number of jenkins test failures we currently see due to timeout exceptions are simply because tests (or test configs) override sensible defaults w/values that are too low to be useful.
> (NOTE: all of these problems / discrepancies also apply to "connect timeout" which should probably be addressed at the same time, but for now i'm focusing on the "socket timeout" since it seems to be the bigger problem in jenkins failures -- if we reach consensus on standardizing some values across the board the same approach can be made to connect timeouts at the same time)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org