[
https://issues.apache.org/jira/browse/SOLR-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814722#comment-16814722
]
Mark Miller commented on SOLR-13389:
------------------------------------
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: [email protected]
For additional commands, e-mail: [email protected]
