Added a primitive "waiter" class for simplifying poll-until-condition-is-met behavior. #300
Conversation
|
Additional example: // Wait until the cloud formation stack status changes
Waiter.run(() -> cf.describeStacks(d -> d.stackName(testStackName)))
.until(r -> r.stacks().get(0).stackStatus() != oldStatus))
.orFailAfter(Duration.ofMinutes(2)); |
| while (Duration.between(start, Instant.now()).compareTo(howLongToTry) < 0) { | ||
| ++attempt; | ||
| try { | ||
| if (attempt > 0) { |
There was a problem hiding this comment.
Won't this always be true? You init attempt to 0, then add 1 to it on line 93 - so even on the very first run it'll be > 0...
There was a problem hiding this comment.
which means we're always waiting 2000 ms before we even attempt it right?
| .changeToken(changeToken) | ||
| .build()); | ||
| Waiter.run(() -> client.deleteIPSet(r -> r.ipSetId(ipSetId).changeToken(newChangeToken()))) | ||
| .ignoring(WAFNonEmptyEntityException.class) |
There was a problem hiding this comment.
Does this just run the operation until there's no WAFNonEmptyEntityException exception?
|
|
||
| private void wait(int attempt) { | ||
| try { | ||
| int howLongToWait = 1000 << attempt; |
There was a problem hiding this comment.
I reckon we should have a more aggressive wait initially - what if we started this at 200 ms? As it stands the waits are going to be:
attempt 1 -> 2000
attempt 2 -> 4000
every other attempt -> 5000
There was a problem hiding this comment.
Yeah, there's also an overflow risk I've fixed. I've done (250, 500, 1000, 2000, 4000) in the latest.
There was a problem hiding this comment.
What if we could throw in a guess of how long we think it will take and then grow from there?
If I think it takes about 4 seconds, then start at 4000 and go 4250, 4500, ...
| while (Duration.between(start, Instant.now()).compareTo(howLongToTry) < 0) { | ||
| ++attempt; | ||
| try { | ||
| if (attempt > 0) { |
There was a problem hiding this comment.
which means we're always waiting 2000 ms before we even attempt it right?
millems
force-pushed
the
millem/it-improvements
branch
from
20b1032 to
9486f0d
Compare
…-is-met behavior. The waiter can execute a function multiple times until the function's response meets a desired state. This is useful for dealing with eventually consistent APIs without having to use arbitrary sleep durations. Also: 1. Fixed error in lambda test where function was not being uploaded, but test expected it. 2. Retry WAF delete-ip-set multiple times in case the IPs had not yet been deleted on the service side.
millems
force-pushed
the
millem/it-improvements
branch
from
9486f0d to
0076962
Compare
The waiter can execute a function multiple times until the function's response meets a desired state. This is useful for dealing with eventually consistent APIs without having to use arbitrary sleep durations.
Also: