Following up on this thread - I finally got around to getting these changes
merged in!
A couple of things to note:
- If you use regular Awaitility, your code will now fail spotless. Use
GeodeAwaitility instead. Now there is no need to set any timeouts, poll
delays, etc in your individual tests.
I typically use 2 MINUTES as the timeout for everything I've worked on in
integration or distributed tests. I believe that whatever the underlying
async action is will still complete well under 2 MINUTES even if a long GC
pause occurs during that window of time. 5 MINUTES is probably longer than
we
I recommend keeping this Awaitility with default timeout separate from any
Rules or MemberVM. I want to be able to use Awaitility in integration tests
and distributed tests that don't use MemberVM or the StarterRules. So from
that POV, I'd prefer the GeodeAwaitility that Dan proposes.
On Thu, Jul
+1 to a single source of member wait calls.
We already have a standard set of await methods for DUnit member VMs,
located in the MemberVM class, and delegated to that class from the
MemberStarterRule. I have a PR outstanding [1] that improves those
methods, too.
For those awaits that are common
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
+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
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
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
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
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
10 matches
Mail list logo
