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

Daniel Fuchs daniel.fuchs at oracle.com
Mon Jul 27 16:24:16 UTC 2020


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.

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


More information about the net-dev mailing list