https://issues.apache.org/bugzilla/show_bug.cgi?id=48488
--- Comment #2 from Jason Brittain <jason.britt...@gmail.com> 2010-02-26 18:54:52 UTC --- I think the behaviour of the server socket backlog has changed in in recent years, at least on Linux, and possibly also on other operating systems. The change appears significant enough to invalidate the acceptCount attribute, and its docs. On recent Linux distributions (where "recent" is defined as having a kernel version that was released more recently than around 6 or 7 years ago -- we don't know an exact number for this), it appears to not matter what you set acceptCount to, all socket connections get accepted, and none get refused, regardless of the other settings on the Connector, such as thread pool settings. For example, with a thread pool of, say 2 threads, max (not growable), I can connect any number of simultaneous TCP client connections to the server socket (I tested up to 1000), and all connections open. It is the Linux kernel doing this, not Tomcat nor Java. We tested this on Mac OS X and Windows as well, and found the same behavior. I remember specifically testing this on some OSs about 13 years ago and found the backlog value to be the determining factor of whether a client connection would get a connection refused or not, when the server software was not accepting new client socket connections. That appears to no longer be the case, at least on the OSs I just tested.. they're all automatically accepted. We also tried the same thing by writing a very simple server program in some other programming languages, just to see if the Java runtime had a bug. The servers written in other languages behaved the same on Linux -- the backlog value is ignored. I did some searching on the net and found this page in the book Fundamental networking in Java: http://is.gd/9g8gU "The backlog parameter specifies the maximum length of the backlog queue. If backlog is omitted, negative, or zero, a system-chosen default is used, e.g. 50. The backlog specified may be adjusted by the underlying platform. If the backlog value is excessive for the platform it is silently adjusted to a legal value. No means exists in Java or the Berkeley Sockets API for discovering the effective backlog value." Even if the OS attemts to use the backlog value we pass in, it may silently change the value, significantly, and there is no way to query what value is being used. In my tests, it appears that the value passed in does not get used at all by the Linux kernel. About Linux, I also found this: http://www.frozentux.net/ipsysctl-tutorial/ipsysctl-tutorial.html#AEN398 Which might be the only way to make the kernel-managed backlog smaller. If a low backlog (acceptCount) value is _not_ ignored on an OS you test, and the server is able to refuse additional connections, we would be interested to know which OS that is, exactly, and what the backlog value was that you used. If there aren't any, then I think the acceptCount attribute should either be removed or the documentation about it should be updated. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
