John,
On 8/11/25 1:17 PM, John Williams wrote:
Hi Chuck,
I tested this on Linux.
- The default somaxconn limit was 4096. I did not see any connection refused
errors with 500 threads.
- When somaxconn was reduced to 128 even, I did not see any connection refused
errors on the client, with as many as 2000 concurrent threads being used to
establish connections.
- When Tomcat's acceptCount was reduced to 200, even for Linux, connection
refused errors returned. However, the concurrent threads creating connections
had to be a much higher number than what was required for Windows before the
connection refused errors showed up.
Any insight into what can be done to avoid connection refused errors at a
relatively lower workload on Windows OS?
Next time you post a new message, please actually post a new message.
With message-threading enabled on the mailing-list, this message looks
like a reply to one you posted way back in September 2024. This makes it
look (to me) like it's a continuation of an old conversation when it's
actually a new thread entirely.
If Windows is essentially ignoring your backlog request, I think your
only option is to raise the number of simultaneous connections Tomcat is
willing to accept.
I'm sorry if the answer to this question is already buried somewhere in
your previous posts (I *did* read them all fairly carefully), but do you
get errors if Tomcat's maxConnections is set to something fairly high,
such as the default 8192? What about -1 (no limit)?
Does this only happen if you literally get 200 truly simultaneous
connection-attempts, or are you running some kind of load-test where you
have N clients trying to make requests as fast as possible? (If you are
using a load-testing tool, please share which one you are using and the
parameters of the test so maybe we can reproduce it.)
It's entirely possible that you will need to do one of the following:
1. Try an Early-Access build of OpenJDK (https://jdk.java.net/26/) to
see if the bug has been fixed as desired.
2. Switch to Linux.
It seems like option #1 is readily testable, so if I were you, I'd
download one of the OpenJDK pre-release builds and just try it. I'm
assuming you are playing around in a dev/test environment where this is
easy, so just go for it. It *probably* won't destroy your computer. ;)
If I'm reading the release schedule correctly, Java 26 should be
generally-available on 2026-04-21 which isn't actually that far away.
-chris
-----Original Message-----
From: Chuck Caldarale <n82...@gmail.com>
Sent: Thursday, August 7, 2025 9:01 PM
To: Tomcat Users List <users@tomcat.apache.org>
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 7, at 18:16, John Williams
<john.willi...@eginnovations.com.INVALID> wrote:
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.
Do you do any warm up of the server before running the actual test? There will
be some slowness in getting the necessary server threads created, even if it’s
only 50 or thereabouts.
For curiosity’s sake, would It be possible to run your test application on Linux with
<Connector acceptCount=“200”> to match the Windows default setting? I’m
wondering if the problem may simply be the thread scheduling overhead in Windows.
- Chuck
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 <n82...@gmail.com <mailto:n82...@gmail.com>>
Sent: Thursday, August 7, 2025 6:26 PM
To: Tomcat Users List <users@tomcat.apache.org <mailto:users@tomcat.apache.org>>
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
<john.willi...@eginnovations.com.INVALID> 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: users-unsubscr...@tomcat.apache.org
<mailto:users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail: users-h...@tomcat.apache.org
<mailto:users-h...@tomcat.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
<mailto:users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail: users-h...@tomcat.apache.org
<mailto:users-h...@tomcat.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
