Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of pid@pidster.com designates
 74.125.82.43 as permitted sender)
Message-ID: <509FB2D8.7080108@pidster.com>
Date: Sun, 11 Nov 2012 14:14:48 +0000
From: Pid <pid@pidster.com>
Organization: Pidster Inc
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Handling requests when under load - ACCEPT and RST vs non-ACCEPT
References: <893793A4A8314F8FA06E6943B8A57171@HP6910P>
 <5099D49E.2060308@apache.org> <EEC5991FE60A41F68FF1AD132477153E@HP6910P>
 <509B1E46.9030007@apache.org> <7C7DA71CB3094C539159D71B5BB356D0@HP6910P>
 <509D5C66.2070104@christopherschultz.net> <509DDD9A.2000903@apache.org>
In-Reply-To: <509DDD9A.2000903@apache.org>
OpenPGP: id=62590808
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig5ADDD5FA75616CAC413F9DCF"

--------------enig5ADDD5FA75616CAC413F9DCF
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/11/2012 04:52, Asankha C. Perera wrote:
> Hi Chris
>> ....processing 1 connection through completion
>> (there are 99 others still running), re-binding, accepting a single
>> connection into the application plus 100 others into the backlog, then=

>> choking again and dropping 100 connections, then processing another
>> single connection. That's a huge waste of time unbinding and
>> re-binding to the port, killing the backlog over and over again... and=

>> all for 1-connection-at-a-time pumping. Insanity.
> I'm sorry but you've misunderstood what I was saying. Yes the example I=

> used showed it for one connection to make it easier to understand what =
I
> was proposing. But in reality you would not stop and start at each
> connection. Remember the two thresholds I was talking about? You could
> stop listening at 4K connections, and start listening again when the
> connections drops to say 3K - and these could be user specified
> parameters based on the deployment.
>=20
> HTTP keep-alive from a load balancer in front would work extremely well=

> under these conditions as established TCP connections are re-used. Any
> production grade load balancer could immediately fail-over only the
> failing requests to another Tomcat when one is under too much load - an=
d
> this would work for even non-idempotent services.

If there's an LB in front, it should be protecting the Tomcat instance
from an excessive number of connections, no?


p


>> You want to add all this extra complexity to the code and, IMO, shitty=

>> handling of your incoming connections just so you can say "well,
>> you're getting 'connection refused' instead of hanging... isn't that
>> better?". I assert that it is *not* better. Clients can set TCP
>> handshake timeouts and survive. Your server will perform much better
>> without all this foolishness.
> If you can, try to understand what I said better.. Its ok to not accept=

> this proposal and/or not understand it..
>=20
> regards
> asankha
>=20


--=20

[key:62590808]


--------------enig5ADDD5FA75616CAC413F9DCF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQn7LZAAoJEGoM2OGpOvr9DaEQAJOX0BYyL8vpS2I/HPe262Ig
zLGhNprBYWdYn2pGvT9BLBK2H4/CmBKlyAHc07zpCLlwX8oXBBYLkgsiRiHjgI3V
raxQlIlc+FJxfjCvSdQrQagTyJ3GKvttCP1VONZ9ceyiBN+JTeYOdT0I061/kWUb
MpvS5ZBRuVxS/VgrQXzXKhORYKHMdh/051nk/wfmi/xlhA6P6ufCi3qIPWsDLix+
d6KKIHuW4N61s0ALph9aLk9o43wIwqXo9Qb9EnxKGqU4aq/M2kzUCONapvc/oICB
JQj+Apbs28wPGvMmol3Nh8USEzlAUuTZ4PK1BOsFbf6JJZIUHD3Zg152qOhx8ZWL
4q+dqLsLnvlhVmNmjRVhcu9Kn2w2d0QBM7Q1ivjUQeHJ+darB6aodfxAVaWeSWxv
64jUWWU95U6VBnSDSDlmCfFqHzuliNHUszUZaMq7aCX/1QzaUu6EEQf065WCkkFm
TnMU29gLzBUzSod5tgxakt0l6LT7f67GCL8jNinylpAZ9taJsV7Dltz0tszfiQPA
JPZaZbzXvFQ0ACRZIviNNFfCS01aXjZDu66GkQjJsyhzAWyle3XJ9EMwe6jIiuGY
QfrfSPJ3s+CweGAbEpyzUQ/jG6R3vZZvF3Z5WpL/gMBL4kgck79Hz5W+Rwk+8nww
vaMnnflGTeeJlGjI1Oxn
=8Qr4
-----END PGP SIGNATURE-----

--------------enig5ADDD5FA75616CAC413F9DCF--