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

Reply via email to