tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <asan...@apache.org>
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

regards
asankha

-- 
Asankha C. Perera
AdroitLogic,http://adroitlogic.org

http://esbmagic.blogspot.com




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


Mime
View raw message