Hi, I am trying to run a spring boot application with an embedded tomcat. In a scenario, where there is a lot of load on the service, I would like tomcat to refuse connections or return something like a 503 Service Unavailable. From what I understand, you could have this behaviour by setting maxConnections and and any additional connections get refused. At least this was how the old blocking io acceptor worked, from what I understand.
The documentation says "The maximum number of connections that the server will accept and process at any given time. When this number has been reached, the server will accept, but not process, one further connection. This additional connection be blocked until [...]". However the documentation doesn't really state what happens if maxConnection+2 connections are reached. I tried to run my application with following settings (embedded-tomcat 9.0.45): maxConnections=3 acceptCount=2 maxThreads=1 processorCache=1 I created an endpoint, which just sleeps for a few seconds and returns a string. When I create 50 separate connection via curl instances to call that service I see the following behaviour with the NIO Acceptor: * 6 http connections are accepted immediately (maxThreads + acceptCount + maxConnections) * 44 http connections aren't established just, but neither are they refused. I will call them "blocked", but different from the specification those are 44 blocked connections and not just 1 * once the first request finishes, the latest (blocked) requests gets a connection and is being processed (not a request from the accept-queue or one of the other already established connections) * when there are no further blocked requests, the requests still get processed in last in first out order * I see some timeouts after a while with this setup, depending on what timeouts I set on curl. The requests without an established connection timeout with "connect-timeout" parameter and the ones with established connections depending on the "max-time" parameter. Now I have a lot of questions and I suspect some bugs, but I wanted to ask on this list first: 1. Is there a way to refuse connections, instead of blocking them? 2. I can't control the connect-timeout of the clients - is there a way to control it on the server side? (I tried to change keepAliveTimeout and connectionTimeout without success) 3. Why doesn't the specification state what happens if many more requests are being made than maxConnections allows for? (esp. with the behaviour being different among acceptors) 4. The processing order is troublesome - early requests get starved by following ones. Why is this lifo instead of fifo? 5. The number of accepted connections is unintuitively. Why are active connections with requests either being processed or being in the accept queue not counted as active connections (actual connections = maxConnections + acceptCount + maxThreads)? 6. What is the difference between requests in the accept queue and requests outside the queue, but still within the maxConnections limit? Any insight would be appreciated. If there is anything in here, that I should report as bug, please let me know. I am happy to file one. Best regards, Paul ________________________________ Pflichtangaben anzeigen<http://www.deutschebahn.com/pflichtangaben/20210430> N?here Informationen zur Datenverarbeitung im DB-Konzern finden Sie hier: http://www.deutschebahn.com/de/konzern/datenschutz
