Checkpoint awaitability

[vietj]

It's often convenient to use a checkpoint as latch to yield the main thread when a condition is met:

Checkpoint checkpoint = ctx.checkpoint();
webClient(callback -> {
  checkpoint.flag();
});

// Await until the checkpoint si met 
// we are on the JUnit thread, so it's ok and very convenient
checkpoint.await();

[jponge]

Should we recommend that over java.util.concurrent classes?

I see the point of your proposal, but I'm wondering if we should mix concerns or not.

[vietj]

are you thinking of CountDownLatch ?

[vietj]

It can also be seen as a CompletionStage as well

[vietj]

imho just await is fine, CompletionStage has other purpose and CountDownLatch is a read/write interface (i.e if you have it you can count() and (which is what flag() does more or less)

[jponge]

Yeah I was thinking about a latch

[vietj]

we could think of Checkpoint to be a class an extend the latch, I'm not sure it would buy anything as it's quite a minimalistic API.

[jponge]

I'd rather compose than extend 😉

[jponge]

So yeah let's think about await

[vietj]

it was not clear if you meant about API reuse or code reuse

it would be great also to clarify that await should throw an exception when the context fails so basically under the hood it would rather be a CompletableFuture that is completed when the checkpoint is completed and completed exceptionally when its context fails.

[vietj]

you can call it awaitSuccess :-)

[cvgaviao]

@jponge , there was any progress on this?

Btw, is there any alternative in order to prevent the test method in main thread, other than Thread.sleep(), to finish while an async procedure are being executed?

[jponge]

@cvgaviao The test method will always execute from the main thread.