tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <>
Subject Re: Handling requests when under load - ACCEPT and RST vs non-ACCEPT
Date Mon, 12 Nov 2012 22:31:12 GMT
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.


Asankha C. Perera

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message