[DISCUSS] Standardize use of awaitility to a higher timeout

2018-07-11 Thread Dan Smith
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 timeou

Re: [DISCUSS] Standardize use of awaitility to a higher timeout

2018-07-11 Thread Udo Kohlmeyer
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 boar

Re: [DISCUSS] Standardize use of awaitility to a higher timeout

2018-07-11 Thread Dan Smith
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 a

Re: [DISCUSS] Standardize use of awaitility to a higher timeout

2018-07-11 Thread Mark Hanson
Hi All, In my humble opinion, I think we should create a single location for timeouts and the timeouts should be the same for similar operations, eg. restarting a locator. Further, I think that if the timeout is exceeded, then it should throw a very clear exception stating what has happened. Th

Re: [DISCUSS] Standardize use of awaitility to a higher timeout

2018-07-11 Thread Jacob Barrett
+1 what Dan said. > On Jul 11, 2018, at 11:16 AM, Dan Smith wrote: > > 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 ge

Re: [DISCUSS] Standardize use of awaitility to a higher timeout

2018-07-11 Thread Mark Hanson
After further discussion, based on GC variability +1 for what Dan said. Thanks, Mark > On Jul 11, 2018, at 12:53 PM, Jacob Barrett wrote: > > +1 what Dan said. > >> On Jul 11, 2018, at 11:16 AM, Dan Smith wrote: >> >> Well, some of these tests are waiting for members to startup, etc. If the

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #975 was SUCCESSFUL (with 2423 tests)

2018-07-11 Thread Spring CI
--- Spring Data GemFire > Nightly-ApacheGeode > #975 was successful. --- Scheduled 2425 tests in total. https://build.spring.io/browse/SGF-NAG-975/ -- This

Geode unit tests completed in 'develop/DistributedTest' with non-zero exit code

2018-07-11 Thread apachegeodeci
Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/110

Geode unit tests completed in 'develop/DistributedTest' with non-zero exit code

2018-07-11 Thread apachegeodeci
Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/110