-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 1.
> - 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 "1" 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
