tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <>
Subject Re: Handling requests when under load - ACCEPT and RST vs non-ACCEPT
Date Thu, 08 Nov 2012 20:46:42 GMT
On 08/11/2012 15:03, Asankha C. Perera wrote:
> Hi Mark
>>>> 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.
> I would consider such production deployment as a risk - a Tomcat crash,
> or even a restart might end up in a soup if another process starts using
> the port in the mean time..

It is not uncommon for monitoring tools to attempt to (re)start a
service when it is observed not to be listening on its designated 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
> Yes, this is correct
>> 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.
> Ok, thank you for considering my proposal. I respect the decision of the
> Tomcat community.
> Hopefully someone else will find this thread useful in future to
> understand the issue better and to overcome it
> regards
> asankha



View raw message