-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Filippo,
On 10/10/19 11:47, Filippo Machi wrote: > Hello everybody, I am trying to understand in which way tomcat is > handling incoming connections. We have a spring boot application in > production that is using tomcat embedded (version 8.x) and since we > are experiencing some issues with Too Many Files open, we would > like to understand properly in which way the application is > handling incoming connections from the clients. Is there any > resource that explains what is in charge of the operating system > and what is in charge of Tomcat. I would like to understand all > the steps a request goes through in order to be handled and alsohow > does the NIO connector works considering mainly those three > parameters: - maxConnections - acceptCount - maxThreads There's a lot of information to give you, and maybe all at once isn't the right approach. Let's start with those three settings you have above . > - maxConnections This one is easy: it's the maximum number of TCP/IP connections that the connector will open. By default for the NIO connector, it's 10000. > - acceptCount This is a hint to the operating system as to how many incoming connections should be allowed to queue-up in the TCP/IP "backlog" before refusing requests. It's easier to explain what happens to clients than to use the "official" terminology if you aren't familiar with it: If you have maxConnections="10" and acceptCount="0" then 10 clients will connect and (assuming none of the first 10 requests complete), the 11th client will get a "connection refused" error. If maxConnections="10" and acceptCount="10" then 10 clients can connect and work begins immediately on their requests. The next 10 clients (assuming none of the first 10 have completed) sit in the TCP/IP backlog queue but don't actually "connect" yet. The 21st client get a "connection refused" error. Once the first client's request completes, one of the "backlogged"/"queued" connections will *actually* connect, and then processing begins on that client's request. Please note that acceptCount is just a hint to the OS. You can set it to "0" and maybe you'll still get a non-zero backlog queue. Or maybe you'll set it to "10000" and only 100 connections will actually be queued. You can't force the OS to do something it doesn't want to do :) > - maxThreads This is easy, too: this is the maximum number of request-processing threads that will be created in order to process requests. This number is *per connector* and so if you have more than one connector with different numbers, you'll get the sum of those two numbers as your total number of request-processing threads in your server. Connectors that are configured separately *do not* share these threads. Connectors configured with an "executor" will share the executor if the names are the same, and you'll only get "maxThreads" threads (and not, for example, maxThreads * 2 for two connectors sharing a single executor). If you are getting TooManyFilesOpen errors, hen you are running out of "file handles". You didn't say which OS you were on, so I'll assume *NIX since that's what I actually know :) Handles to actual on-disk files are "file descriptors". But network connections are also file descriptors, and they can really add up. Each process has a limit on the number of file descriptors that it can create before the OS refuses to create new ones. This is a protection the OS places on processes so they don't use up all the resources in the system. Sometimes, this limit is just too low and needs to be raised for e.g. Tomcat to be able to do its job. Sometimes it means that you have things misconfigured. What does your configuration look like and what are the circumstances under which you are getting these "too many open files" errors? - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2fcZ0ACgkQHPApP6U8 pFhhcQ/5Adc2wyu0GTQrX+H6BMlB6N7VSchz2rHV5cM+jMatCFKcvkYAqL6m0Rbn jdlzakE26nQ+nEBThAJB9b6cs1DNWApE4TtZTuItdVNhik0ClQkBhYFrZ4HpsXsx ZAsgPgVeYNb9kXXkIRstjnia+vq6i3/VarYdJXlbnEjXzu+eyC8+HQh8DlyIO6hr sTmgPb1Iw7+Z1WM1oNA1E5dmxF2R/Q6RgWsFMGm9BniDG/0FFiHHOr+71LQqe/DH e72Gh5Wcwy8i8rOkSA/OkGJ8wZvkHHEd+VqCI3hmRt7mGyOKoC8RQBpp5RbFkfFz KxdzJrMTQ64gMXD/bPNT3TYBft1j84DYHwyktzBEPBhZgjuTdd1R4eOFmGLuCcqm 1NE0aqvCCRnVcPhEfewz2MENe4c9QF0N8YTqgvmTV6P1v1fTE1C4t03fA/5dsGvx ksVKiJjouakPMRQD/lsdY0kuF7rlDwPwDs0cbx94e/FeiiTht2Mb8YiOToLEk/4C 95dTdEUhNX+i/gK6BduhSCfggNb5eUGj+VExH+OQD0Y9f9exaqzLM7sTYaCEh8uI Co/MkpiqKdIddsZnsSYKn5tgfYYJSiwT8GZAuv/x5Dj7ZCiTZFy85/cuA0GVWpqz pMPMU6v4jnIo5RiIBTonJ9uKOElYA5MKibgwa2aZ+03F0y7MuV4= =F7QI -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
