tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Handling requests when under load - ACCEPT and RST vs non-ACCEPT
Date Mon, 05 Nov 2012 23:25:41 GMT
Hash: SHA1


On 11/5/12 8:36 AM, Asankha C. Perera wrote:
> Hi Chris / Mark
>>> Or you could just read the configuration documentation for the 
>>> connector. Hint: acceptCount - and it has been there since at 
>>> least Tomcat 4.
> The acceptCount WAS being used, but was not being honored as an end
> user would expect in reality (See the configurations I've shared at
> the start)
>> If HttpComponents works as the OP expects, I wonder if he'd be
>> willing to give us the configuration he uses for *that*? Perhaps
>> there is some kind of TCP option that HttpComponents is using
>> that Tomcat does not.
> Whats done by HttpComponents is essentially turn off interest in 
> SelectionKey.OP_ACCEPT [1] if I remember [2]. Check the code of
> the DefaultListeningIOReactor.pause() and resume() [3]

So I looked at all your references (including the incorrect reference
to Javadoc instead of Java code) and not surprisingly the most
informative was the http-components mailing list thread[1]

I have done some digging.

First, evidently, "acceptCount" almost does not appear in the Tomcat
source. It's real name is "backlog" if you want to do some searching.
It's been in there forever.

Second, all three connectors (APR, JIO, NIO) (through their
appropriate Endpoint implementation classes) faithfully configure the
backlog for their various sockets:

        // Bind the server socket
        int ret = Socket.bind(serverSock, inetAddress);
        if (ret != 0) {
            throw new Exception(sm.getString("endpoint.init.bind", ""
+ ret, Error.strerror(ret)));
        // Start listening on the server socket
        ret = Socket.listen(serverSock, getBacklog());

                if (getAddress() == null) {
                    serverSocket =
                } else {
                    serverSocket =
                            getBacklog(), getAddress());

  (Note: serverSocketFactory.createSocket calls new ServerSocket(port,
backlog[, address]))

        serverSock =;
        InetSocketAddress addr = (getAddress()!=null?new

So, barring some JVM bug, the backlog is being set as appropriately as

Third is the notion of playing with OP_ACCEPT on a selector. I'm no
NIO expert, here, but I don't understand why adding OP_ACCEPT to the
SelectionKey would change anything, here: the socket handles the
backlog, and the behavior of the selector shouldn't affect the OS's
TCP backlog. Doing so would be incredibly foolish: forcing the
application to react to all incoming connections before they went into
the backlog queue would essentially obviate the need for the backlog
queue in the first place.

If you can suggest something specific, here, I'd certainly be
interested in what your suggestion is. So far, what I'm hearing is
that "it works with HttpComponents" but I have yet to hear what "it"
is. Are you saying that, basically, NIO sockets simply do not have a
backlog, and we have to fake it using some other mechanism?

- -chris

Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


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

View raw message