-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Asankha,
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:
AprEndpoint:
// 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());
JioEndpoint:
if (getAddress() == null) {
serverSocket =
serverSocketFactory.createSocket(getPort(),
getBacklog());
} else {
serverSocket =
serverSocketFactory.createSocket(getPort(),
getBacklog(), getAddress());
}
(Note: serverSocketFactory.createSocket calls new ServerSocket(port,
backlog[, address]))
NioEndpoint:
serverSock = ServerSocketChannel.open();
socketProperties.setProperties(serverSock.socket());
InetSocketAddress addr = (getAddress()!=null?new
InetSocketAddress(getAddress(),getPort()):new
InetSocketAddress(getPort()));
serverSock.socket().bind(addr,getBacklog());
So, barring some JVM bug, the backlog is being set as appropriately as
possible.
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
[1]
http://old.nabble.com/Controlling-%22acceptance%22-of-connections-tt27431279r4.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlCYSvUACgkQ9CaO5/Lv0PCpNgCfXdjSELy0aaPFHfQCZMWoRfj5
gecAoI5vxhKbJfyLrdG8z97c5Xc1bS4e
=O65S
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
