Hi Daniel,
thanks for the reply and clarifications
apologies for the distraction
regards
Mark
________________________________
From: Daniel Fuchs <daniel.fu...@oracle.com>
Sent: Thursday 16 May 2019 09:19
To: mark sheppard; Chris Hegarty; OpenJDK Network Dev list
Subject: Re: RFR: 8223716: sun/net/www/http/HttpClient/MultiThreadTest.java
should be more resilient to unexpected traffic
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
