On 27/07/2020 17:24, Daniel Fuchs wrote:
Hi Michael,
On 24/07/2020 16:38, Michael McMahon wrote:
Daniel,
That's all fine. Concerning the test, I think the approach looks good,
but I wonder if instead of just synchronizing on the CFs to make
the cancel happen at the same time always, would it be useful to have
a test mode
where the cancel occurs after different lengths of time to try and
exercise
different code paths depending on when exactly it happens?
> Michael.
I am not sure what you mean by that. There are two test species,
the POST and the GET.
The POST is the only one where the interrupt happens "at the same
time always" - when sending the request body.
The GET is basically racy - the interrupt can happen at any time,
though obviously only after the CF has been returned.
The server latency is there to help ensure that the interrupt
will happen before the full response body is received.
The code is technically racy on the GET test, but it's often the case
when you want
something to be racy then it turns out not to be in practice, 99 times
out of a 100 anyway
(figures made up). I was thinking you could put a random sleep on the
client side before calling
cancel (say between 1ms and the SERVER_LATENCY constant). Print out the
random value too
in case it finds a problem.
- Michael
We could certainly add more test - to try and interrupt at
different places, but it might be prudent to do this in
another test file: the combinatory matrix for the current
test is large enough; It already takes into account
upgrades and non upgrade scenarios - which makes it both
verbose and not very fast.
The CountDownLatches are mostly there to figure out whether
dependent actions have been called.
best regards,
-- daniel
