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. p >> 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 > -- [key:62590808]
signature.asc
Description: OpenPGP digital signature
