On 19/05/2021 13:32, Paul P Wolf wrote:
<snip/>
So we have:
maxThreads=4
maxConnections=10
acceptCount=20
<snip/>
The processing time of each request is 10s (thanks to a 10s sleep, which blocks
the Thread).
So here is what I see instead (note I don't guess the response time, but do
actually see/measure it):
0s - 4 requests processing, 11 connections maintained, 20 connections in
acceptCount, 19 not in acceptCount
5s - 4 requests processing, 11 connections maintained, 20 connections in
acceptCount, 0 not in acceptCount, 19 timed-out
OK, that looks like clients with a connection timeout of 5s.
10s - 4 requests processing, 11 connections maintained, 16 connections in
acceptCount, 0 not in acceptCount, 19 timed-out, 4 requests processed
20s - 4 requests processing, 11 connections maintained, 12 connections in
acceptCount, 0 not in acceptCount, 19 timed-out, 8 requests processed
30s - 4 requests processing, 11 connections maintained, 8 connections in
acceptCount, 0 not in acceptCount, 19 timed-out, 12 requests processed
40s - 4 requests processing, 11 connections maintained, 4 connections in
acceptCount, 0 not in acceptCount, 19 timed-out, 16 requests processed
50s - 4 requests processing, 11 connections maintained, 0 connections in
acceptCount, 0 not in acceptCount, 19 timed-out, 20 requests processed
60s - 4 requests processing, 7 connections maintained, 0 connections in
acceptCount, 0 not in acceptCount, 19 timed-out, 24 requests processed
70s - 3 requests processing, 3 connections maintained, 0 connections in
acceptCount, 0 not in acceptCount, 19 timed-out, 28 requests processed
80s - 0 requests processing, 0 connections maintained, 0 connections in
acceptCount, 0 not in acceptCount, 19 timed-out, 31 requests processed
The interesting thing to note is, that contrary to your statement, I don't see
timeouts for requests in the acceptCount/backlog.
Two possibilities there.
1. The write timeout is > ~70s.
2. The write is buffered in the network stack (more likely in the client
I think) and the read timeout is > ~70s.
2 strikes me as more likely than 1.
With a request body bigger than the total amount of buffering in the
client and server network stacks (typically much larger than you might
expect) I think you'll see different results, namely twrite timeouts for
client connections still in the acceptCount - assuming the write timeout
is less than ~70s.
To verify my interpretation, I increased the acceptCount and I saw that the
time outs decrease by the same number. I decreased the acceptCount and saw that
the time outs increase.
I agree that is a strong indication that your interpretation is correct.
Further, I don't see anything to suggest your interpretation is incorrect.
The behaviour seems 100% predictable to me... just not as expected based on the
documentation.
I was going to ask which bit of the documentation but you cover that below.
Not up to Tomcat. Tomcat can only call Socket.accept() and does so
under the control of maxConnections.
Connection refused == acceptCount/backlog full (or no listening socket).
Connection refusal is entirely under the control of the OS and will be
driven largely by the actual value of acceptCount/backlog.
So if it is not up to Tomcat, then the documentation "Any further simultaneous requests will
receive "connection refused" errors" is clearly wrong, isn't it?
That statement in the docs ignores acceptCount so it certainly needs
updating to reflect that.
Beyond that I suspect we are getting into variation in behaviour between
operating systems. There might also be a local host vs remote host
aspect but I don't think that is a factor here. The bigger factors will
be the timeouts configured on the client, the network stack buffering
behaviour and how the OS handles new connections when the acceptCount is
full.
I think if we replaced "connection refused" with "connection refused or
connection timeout" that should cover the possible variations.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
