Timir Hazarika wrote:
This is not an accept problem, this is a problem with having serviced a
request via a socket and then closing the connection. Given that you
can't avoid accepting connections on a useful web server, you will not
be able to prevent them from going through their natural lifecycle.
Chris,
Thanks. I finally chose to write my own endpoint/HTTP protocol handler to
better address the use case of immediate connection reset under load
conditions. The acceptor logic in custom code simply closes socket when
there's no free worker available.
You'll notice in current implementation of tomcat JIOEndpoint, that the
acceptor thread waits for a free worker thread instead.
I guess I do not understand what your custom code achieves, as compared
to just setting the acceptCount attribute to 1 or so.
Suppose one request takes approximately 3 s to process.
Suppose that at time T0, you have 100 worker threads available to
process requests.
Starting at time T0, 110 requests (R001-R110) arrive, inside a 3-second
period.
The first 100 (R001-R100) will get a free worker.
The next 10 (R101-R110) will be rejected, since there is no free worker.
At time T0 + 3.02s, the worker who got the first request R001 finishes,
and becomes available.
At time T0 + 3.03s, a new request R111 comes in.
It will find an available worker and will be processed.
So, requests R101-R110 which came in first are rejected, but request
R111 which came in much later is accepted.
Suppose instead we have the normal scheme, with an accept queue length
of 100 (acceptCount="100").
Suppose that at time T0, you have 100 worker threads available to
process requests.
Starting at time T0, 110 requests (R001-R110) arrive, inside of a
3-second period.
The first 100 (R001-R100) will get a free worker, and start being
processed right away.
The next 10 (R101-R110) will be queued, since there is no free worker.
At time T0 + 3.02s, the worker who got the first request R001 finishes,
and becomes available.
Request R101 is now accepted, and starts being processed.
At time T0 + 3.03s, a new request R111 comes in.
There is no available worker, so it will be queued, behind R110.
As soon as workers becomes available, R102-R111 will be processed, in
the order in which they came in.
It is only if the accept queue gets to be totally full (with 100
requests being processed, and 100 waiting), that subsequent requests
would start to be discarded.
The socket accept queue is basically a "shock absorber". It allows a
temporary surge in requests to be absorbed, while workers are
temporarily overloaded. As soon as some capacity is available, the
first request in that queue will be accepted and processed. Then the
next one.. By increasing/decreasing the acceptCount, you determine how
big your shock absorber is, without using up too many resources.
With your scheme, you are just transforming this shock absorber into a
rigid closed door, equivalent to setting acceptCount to 1. And you are
allowing some requests to "jump the queue" compared to others.
Or did I miss something ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
