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
