Then read about Executors. They are a better idea.
> and what is the optimum value in Unix machine?
There isn't anything UNIX-specific about the optimum value. The
default is 10,000 for NIO/NIO2 and 8192 for APR (I'm not sure why
there is a difference in the defaults; perhaps we should fix that),
which "ought to be enough for anyone".
The proper value for your environment is highly dependent upon your
use-case(s). If you tell us a little more about what you are doing,
perhaps we can give you a better answer.
Actually I am trying to understand the attributes acceptCount vs
maxConnections. Assuming this is the maximum socket connections tomcat can
handle In a time and this can be restricted with ulimit -f in linux.
On Fri, Jan 11, 2019 at 12:34 PM Christopher Schultz <
[hidden email]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> On 1/11/19 10:20, Rajendra Popuri wrote:
> > What is maxConnections attribute in Tomcat
> It is all but deprecated IMHO.
> http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#Standard_Implem > entation
> Search for "maxConnections".
> Then read about Executors. They are a better idea.
> > and what is the optimum value in Unix machine?
> There isn't anything UNIX-specific about the optimum value. The
> default is 10,000 for NIO/NIO2 and 8192 for APR (I'm not sure why
> there is a difference in the defaults; perhaps we should fix that),
> which "ought to be enough for anyone".
> The proper value for your environment is highly dependent upon your
> use-case(s). If you tell us a little more about what you are doing,
> perhaps we can give you a better answer.
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ >
> -----END PGP SIGNATURE-----
> To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] >
On 1/11/19 12:52, Rajendra Popuri wrote:
> Actually I am trying to understand the attributes acceptCount vs
They are both limits, but are implemented in different places.
The "acceptCount" is implemented in the TCP/IP stack of your operating
system, and it's a queue of incoming connections that are allowed to
stall and await the application-layer actually accepting the
connection. Once the application "accepts" the connection, it is
considered to be "connected". When it's in the "accept" queue, the
client is blocking on the connection but no useful work will be
The maxConnections is the number of connections that Tomcat (really
Java, or APR in the case of the APR/native connector) is willing to
accept from the OS's TCP/IP queue (above).
If you have the default configuration, you'll have acceptCount=100 and
maxConnections="10000". If you get 100 simultaneous connections (on a
server with no established connections), they will all immediately be
accepted by Tomcat and the requests will be executed.
If those connections remain open (keepalive, additional requests,
etc.) and another 10100 connections are opened by new clients, this
1. The first 9900 connections will be accepted by Tomcat
2. The next 100 connections will be queued in the OS's TCP/IP stack
3. The final 100 connections will be refused
Once some of the connections accepted in #1 above have been closed,
the TCP/IP stack's connection queue will empty into the application
(Tomcat will accept those connections) and any new connections being
made will then go into the same queue.
It's interesting that the OS is not actually *required* to maintain
the accept-queue-size requested by the application. The Linux man page
for listen(2) has this to say:
If the backlog argument is greater than the value in
/proc/sys/net/core/somaxconn, then it is silently truncated to that
value; the default value in this file is 128. In kernels before
2.4.25, this limit was a hard coded value, SOMAXCONN, with the value 128
BSD (Darwin) says this:
The backlog is currently limited (silently) to 128.
So it almost doesn't matter what you set this value to. Practically,
it will likely be limited *for you* to some other value.
IMHO, I'd leave acceptCount at the default or even *lower it*. I'd
rather have clients get "connection refused" errors than overwealm my
server or create a backlog of requests that is very long. Google for
"buffer bloat" and you'll get a sense of my reasoning.
If one server can't accept enough connections to support by web
service, then I need more servers, not more queuing.
> Assuming this is the maximum socket connections tomcat can handle.
Tomcat can handle lots of connections. Your application is much more
likely to be the bottleneck, here. It probably doesn't make sense to
accept 1,000,000 connections if your application can really only
handle 1,000 simultaneous requests.
> In a time and this can be restricted with ulimit -f in linux.
ulimit -f changes file-size limits, not network limits. You are more
likely to require a change in the number of open file-descriptors (-n)
per process than anything else.