tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <>
Subject Re: Handling requests when under load - ACCEPT and RST vs non-ACCEPT
Date Thu, 08 Nov 2012 15:03:00 GMT
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..
> 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


Asankha C. Perera

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message