Well, some of these tests are waiting for members to startup, etc. If the
machine they are running on is slow, that could take more than a minute.

The point here is that these are not tests of how long it takes do a geode
operation. That's what performance tests are for. These tests just have an
atMost because we want them to fail, rather than hang, if the assertion is
never satisfied. Because these tests should always pass in a variety of
environments, we should set atMost to be something really large.

Performance tests that have assertions about timing need to run on known
hardware, and generally need to assert things like 99.9% the response time
is within this window. That's not what this test suite is.


On Wed, Jul 11, 2018 at 10:05 AM, Udo Kohlmeyer <u...@apache.org> wrote:

> Hi there Dan,
> Whilst 5min seems to be a viable option, I believe that knowing how long
> an operation should take and reacting if it doesn't complete in that time
> is better than waiting a standard amount of time. I like the faster
> feedback option, rather than the standard timeout across the board. Now,
> that said, crazy timeouts like 1-10s are maybe a little low.
> Maybe 1min rather than 5min? With exception to disk recovery tests, which
> feasibly could take more than 1min. I cannot think of a single operation in
> Geode, that should realistically should take more than 60s.
> --Udo
> On 7/11/18 09:07, Dan Smith wrote:
>> Hi all,
>> We have a bunch of tests that are using awaitility. It seems like every
>> tests is picking some random number of it's timeout, usually in the range
>> of 10-60 seconds.
>> I'd like to change all of our tests to use a standard timeout that is much
>> higher, to avoid worrying about whether our timeouts are to low. So I
>> propose introducing our own GeodeAwaitility class that sets a timeout of 5
>> minutes and replacing all of our usage with that.
>> -Dan

Reply via email to