8245462: HttpClient send throws InterruptedException when interrupted but does not cancel request

[Michael McMahon]

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