Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4B47A834.2070401@christopherschultz.net>
Date: Fri, 08 Jan 2010 16:48:36 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: limit number of connections tomcat accepts
References: <201001060903.57300.pbeichert@web.de>
 <4B44951A.4010902@christopherschultz.net>
 <201001080902.48923.pbeichert@web.de>
In-Reply-To: <201001080902.48923.pbeichert@web.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter,

On 1/8/2010 3:02 AM, Peter Beichert wrote:
> Thank you for your help. The good new is, that Tomcat really works like it 
> supposed to. The problem is, that the operating system holds all the 
> connections which did not receive an acknowledgement from the server.

This is what "acceptCount" is supposed to configure. Is that not working
for you? What JVM are you using?

> When monitoring the tcp-connections during the tests with netstat, I could 
> see, that the number of established connections was the sum of threads plus 
> the number of queued requests. All other connections could be observed at the 
> server with a SYN_RECV state. As soon as tomcat finished one request, a new 
> connection was acknowledged and the number of connections with the SYN_RECV 
> state decreased by one.
> 
> The value of the maximum remembered connection requests in Linux is the Kernel 
> parameter tcp_max_syn_backlog which is by default 1024. It can be reduced with 
> the /sbin/sysctl command.

Good to know, though I would have expected acceptCount to work properly.
My understanding of acceptCount is that the socket listener will receive
at most maxActive concurrent requests. After that, acceptCount incoming
requests will be queued in the TCP/IP stack, and subsequent requests
will get a connection refused. If the client has a timeout and/or retry
configured, then that will confuse the issue but the initial connection
should be refused.

Once a request has been completed and the socket is closed, the queue is
processed and another incoming request is free to be queued by the
TCP/IP stack.

I'm curious as to exactly how your observations stack up against that:
are you saying that, in spite of your acceptCount="5", you're
effectively getting acceptCount="1024" because of how your kernel behaves?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktHqDQACgkQ9CaO5/Lv0PCM5QCgjkVT7rZYAS6Z50sGlqLGAqkx
hp0An3jV9aklDaTm8or65Gwyot8Xc5Gb
=PC+9
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org