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