Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Message-ID: <509B8050.2050605@apache.org>
Date: Thu, 08 Nov 2012 09:50:08 +0000
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64;
 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>
 <509B2880.1030902@apache.org>
In-Reply-To: <509B2880.1030902@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 08/11/2012 03:35, Asankha C. Perera wrote:
> Hi Esmond

>> Closing the listening socket, as you seem to be now suggesting, is a
>> very poor idea indeed:
> I personally do not think there is anything at all bad about turning it
> off. After all, if you are not ready to accept more, you should be clear
> and upfront about it, even at the TCP level. Having different thresholds
> to stop listening (say at 4K), and to resume (say at 2K) would ensure
> that you do not start acting weirdly by starting/stopping/starting/..
> acceptance around just one value.
>> what happens if some other process grabs the port in the meantime:
>> what is Tomcat supposed to do then?
> In reality I do not know of a single client production deployment that
> would allocate the same port to possibly conflicting services, that may
> grab another's port when its suffering under load.

Just because it wouldn't cause a problem for a limited subset of Tomcat
users - your clients - does not mean that it would not cause problems
for other Tomcat users.

> I cannot see any other issues of turning off accepting - and I am
> curious to know if anyone else could share their views on this -
> considering real production deployments

The problems have already been explained to you. Another process could
use the port.


Having reviewed this thread the problem you seem to be trying to solve
is this:
- a load-balancer is in use
- Tomcat is under load
- a client attempts a connection
- the connection is added to the TCP backlog
- Tomcat does not process the connection before it times out
- the connection is reset when it times out
- the client can't differentiate between the above and when an error
occurs during processing resulting in a connection reset
- the client doesn't know whether to replay the request or not

First of all, it is extremely rare for Tomcat to reset a connection once
processing has started. The only circumstances where I am aware that
would happen is if Tomcat is shutting down and a long running request
failed to complete or if Tomcat crashes. All other error cases should
receive an appropriate HTTP error code. In a controlled shut down load
can be moved off the Tomcat node before it is shut down. That leaves
differentiating a Tomcat crash during request processing and the request
timing out in the backlog.

For GET requests this should be a non-issue since GET requests are meant
to be idmepotent. GET requests can always be re-tried after a TCP reset.

For POST requests, use of the 100 Continue status can enable the client
to determine if the headers have been received. A TCP reset before the
100 continue response means the request needs to be re-tried. A TCP
reset after the 100 continue response means it is unknown if a retry is
necessary (there is no way for the client to determine the correct
answer in this case).

Given the above I don't see any reason to change Tomcat's current behaviour.

Mark


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