RFR: 8223716: sun/net/www/http/HttpClient/MultiThreadTest.java should be more resilient to unexpected traffic

[Daniel Fuchs]

Hi Mark,

AFAIU the test wants to verify that connections are reused.
It does that by creating N (N=5) threads that will hammer
at the server concurrently.

Because there are N threads, then there can't be more than
N concurrent requests, and therefore there should not be
more than N connections and therefore N workers.

What we observe is that from time to time the server receives
N+1 connections. It happens very infrequently - but I've seen it
a couple of times.

When that happens - I usually that the 6th connection is created
much later in the game - and by that time one of the other connections
(usually worker 0) no longer seems to receive anything.

So for some reason one connection has been closed, and a
new one has been created to take up the load.
I have yet not clue why that happens, and JDK-8223783 has
been logged to followup on this.

In the mean time I modified the test to not fail but
print a warning when N+1 connections are created when N are
expected.

best regards,

-- daniel


On 16/05/2019 00:35, mark sheppard wrote:
> Hi Daniel,
>    a little feedback on the test and some observations.
> was curious about this test, mainly that debug wasn't synchronized
> and expected to see interleaved output from clients and servers.
> So ran the test … had look at the output, which wasn't interleaved
> and totals all seemed to matched
> 
> 
> as I understand it the test outline is that
> create Server
> accept client connection
> create Worker for connection
> start worker
> 
> create 5 clients
> create HttpUrlConnection to test server
> send 20 requests
> 
> should see total 100 requests
> 20 from each client and 20 received by each worker
> 
> On looking at the output a little closer things seemed a little off
> or my observations maybe wrong. Each of the workers i.e. the client
> handlers in the server didn't receive 20 request but a random number
> of requests. This seems to exhibit some of the pathology of the original 
> bug ?
> 
> Ran the test multiple times and a total of 100 requests received but 
> randomly distributed across
> the workers
> 
> To observe the client side output I amended test constructor to take an  
> int clientId and used that
> in that clients debug output.
> 
> FWIW attached in a file with analysis of a few test runs output.
> 
> regards
> Mark