[teststabilization] RFR: 8233403: Improve verbosity of some httpclient tests

[Daniel Fuchs]

Hi Chris,

Thanks for the review! Meanwhile one of the test jobs I had
launched completed and showed one of the intermittent
SortRequestBody failures - and I was able to see the root
cause!

It is a test bug: the server uses a counter to figure out
what result the client will expect in its next response, and
I could see that this counter got de-synchronized: the client
sent 42 requests but the counter got incremented only 41 times
and that caused the test for the next supplier to fail in
timeout (see traces below). So I've taken the opportunity
to fix that in the test as well.

Only changes compared to previous webrev are in
ShortRequestBody.java.

http://cr.openjdk.java.net/~dfuchs/webrev_8233403/webrev.01/

best regards,

-- daniel

========================================================

Server: count=40, offset=6
Server: expecting 1 bytes
Server: actually read 0 bytes
Caught expected: java.util.concurrent.ExecutionException: 
java.io.IOException: SocketTube(42) [HttpClient-43-Worker-2] Too many 
bytes in request body. Expected: 14, got: 17

---- next supplier ----

Server: got connection
Server: count=41, offset=6
Server: expecting 14 bytes
java.util.concurrent.TimeoutException
	at 
java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1957)
	at 
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2092)
	at ShortRequestBody.success(ShortRequestBody.java:171)
	at ShortRequestBody.main(ShortRequestBody.java:140)


On 01/11/2019 18:28, Chris Hegarty wrote:
> 
> 
>> On 1 Nov 2019, at 17:57, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi,
>>
>> Please find below a change to some HttpClient tests that should
>> improve diagnosability if they fail:
>>
>> 8233403: Improve verbosity of some httpclient tests
>> https://bugs.openjdk.java.net/browse/JDK-8233403
>>
>> webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8233403/webrev.00/
> 
> Good to shorten the output when there is a failure. Looks good.
> ( I didn’t know that the same data providers were evaluated each
>    time, but now I do ;-)  )
> 
> -Chris.
>