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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
