Chuck,
I am aware that the TCP backlog queue and concurrent connections are different.
The problem occurs before the connection is fully established.
My testing scenario is:
- A total of 500 connections are attempted concurrently using 500 threads from
a client application. These connections get a simple page and the response
should be instantaneous.
- About 10-40% of the connections are refused (varies from one test run to
another - but it's never 0).
- Tomcat threads does not reach anywhere close to 500.
- Changing the acceptCount in Tomcat's connector has no effect.
- netstat shows connections reaching less than 50.
- The testing is based on the latest available downloadable version of JDK 21
and Tomcat 11.
- From what I can see, the bottleneck is NOT in Tomcat.
- I have tested after restarting tomcat and making sure there are no other
requests to the application other than the 500 connections I have initiated.
The Connector configuration is below:
<Connector executor="tomcatPool"
protocol="org.apache.coyote.http11.Http11Nio2Protocol" port="443"
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
scheme="https" secure="true" SSLEnabled="true"
enableLookups="false" acceptCount="12000"
acceptorThreadCount="8" connectionTimeout="300000" maxPostSize="-1"
maxKeepAliveRequests="1" maxConnections="5000" URIEncoding="UTF-8"
useSendfile="false" tcpNoDelay="true" compression="force"
compressionMinSize="2048" compressibleMimeType=" text/html,text/xml,text/plain,
application/octet-stream,application/xml,text/javascript,text/css,image/png,
application/x-javascript,application/javascript,application/json,application/xhtml+xml,application/xml+xhtml"
noCompressionUserAgents="gozilla, traviata" >
<SSLHostConfig honorCipherOrder="true" ciphers=",..."
certificateVerification="none" protocols="TLSv1.2+TLSv1.3"
sslProtocol="TLS"><Certificate certificateKeystoreFile="binfile"
certificateKeyAlias="cert" certificateKeystorePassword="..." /></SSLHostConfig>
</Connector>
Regards,
-----Original Message-----
From: Chuck Caldarale <[email protected]>
Sent: Thursday, August 7, 2025 6:26 PM
To: Tomcat Users List <[email protected]>
Subject: Re: Tomcat acceptCount limitation and connection refused errors
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
> On 2025 Aug 6, at 18:29, John Williams
> <[email protected]> wrote:
>
> I have Tomcat 11 running on Windows. When I get a spurt of connections, the
> client sees "Connection Refused" errors sporadically. I have tried increasing
> the acceptCount for the connector and that does not help.
>
> From what I am reading, this appears to be a because of the default TCP
> Backlog setting at the OS level. Windows has this limit set to 200, so if
> there are more than 200 simultaneous connection attempts, some connections
> get refused.
>
> I have verified that there is no CPU/memory bottleneck on the server,
> ephemeral port usage is very low, so this is definitely a TCP backlog issue.
>
> On Windows, there appears to be a way to increase the TCP backlog queue .
> This setting is at the socket level, rather than an OS setting.
>
> Does Tomcat provide a way to increase the OS level TCP backlog queue length,
> and if not, can this be considered in the roadmap?
>
> This seems to be a scalability issue for Tomcat - 200 concurrent connection
> limit appears to be a very low number. Please correct me if I am wrong.
The backlog queue size is not the limit for the number of concurrent
connections - they are distinct entities. A connections request sits in the
backlog queue until the server accepts it, which usually occurs extremely
quickly - unless the actual concurrency limit as specified in your <Connector>
element has been reached. The backlog limit only comes into play if Tomcat
cannot accept additional connections for some reason, such as the thread limit
being reached.
Since you didn't provide your Tomcat <Connector> configuration, no actual
answers can be provided - just speculation.
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
