Hi Esmond
To reiterate what Christopher said, if you close the listening socket
because you think you can't service one extra client, you will lose all the
connections on the backlog queue, which could be hundreds of clients, that
you *can* service.
I do not see a problem here. We develop software that routes millions of
requests to dozens of Tomcat instances. For a single instance of Tomcat
- the problem is much simpler. It should just handle the maximum number
of connections its configured for. If each single Tomcat instance
behaves slightly better (i.e. refuse vs reset), we can avoid making any
guesses about whether Tomcat has crashed etc - if a TCP level reset on
the connection is received instead of a refused, and can perform much
better support independent of whether a service or method is idempotent.
This context is different from a clients making say JSP calls for a UI.
The end clients connecting to us may use HTTP or HTTPS, with out without
keep-alives etc. We will handle those connections, and then route, load
balance and failover against dozens of Tomcats. Now each connection we
establish to a Tomcat will almost always be a well kept Keep-Alive,
which is re-used even for different requests originating from multiple
external clients. So if we are managing say 10K connections, maybe 4K
with keep-alive and 6K without with our clients, we will still use a
limited number of keep alive connections to each single Tomcat we load
balance and fail over against.
Yes, we can and do support connection throttling at a slight cost to
safeguard a single Tomcat from receiving more connections that it can,
but if Tomcat was able to not reset connections at the TCP level - we
can perform our task much better, and I do not think this will cause any
problem to any other use cases of Tomcat - if we can just enable this
behavior with a configuration parameter
In addition, those clients will then get exactly the behaviour that you are
complaining about: a successful connection and then a 'connection reset'
when doing I/O.
No, they will not get an ACK to the SYN packet which is much better.
Else they will get an ACK, and the Tomcat will start receiving a part or
whole payload - and then reset which is nasty - this is the main difference
There is no possibility of this proposal being accepted.
I do not understand the negativity here.. I was wondering if I should
take this discussion to the dev@ list since I've already discussed it on
user@. I wish Tomcat had a Wiki or used JIRA where I could submit this
as a proposal - maybe with a diagram/screen shots etc - and make end
users vote for this across a few months - until we find that this
solution has a value.
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
