there are no threads nor forks and backlog is set to 511 (Apache's default value).
and client always waits for rrequst to complete before sending a new one.
Peter Edwards wrote:
On Fri, 18 Feb 2005 16:18:41 +0300, Deomid Ryabkov <[EMAIL PROTECTED]> wrote:
I have a strange case of occasional refused connect()'s. The system is running 4.10-STABLE.
This was originally reported by one of our developers.
The test script he provided is a simple Perl script that repeatedly
fetches an URL
from Apache running on this same server.
In the run of 2000 iterations, there are 5-10 random errors fetching the
URL.
After further investigation and digging, I uncovered the true cause of
the error:
connect() returning ECONNREFUSED.
To see if this was somehow related to Apache, I wrote my own simple
server that
accept()'s a connection, read()'s what supposed to be request and
write()'s a stereotypic reply,
thus resembling an HTTP request/reply conversation.
The number of sporadically occuring connect() errors has increased somewhat,
maybe due to quicker turnaround of my stub-server.
The question is - why do connections get refused at all?
I can think of no valid reasons...
Here's one:
In your stub server, what do you set the backlog to in the call to listen(2)?
By the time you get the file descriptor for the new call from accept(), the kernel has already established the TCP/IP connection, and is maintaining state (ie, using resources) for it
If you take a while dealing with this new call, (starting a thread, forking, or even processing the connection), then by the time you invoke accept() again, any number of clients may have attempted to connect to you, and the kernel needs to maintain state for every connection that has been requested.
The backlog on the listen call indicates how many of these connections the kernel should hold on to: If the number of unaccept()ed connections reaches the backlog, you'll start to get ECONREFUSED errors at the client. If your stub server is single-threaded, this'll be pretty much guaranteed to happen if the number of clients exceeds the backlog on ths server's listening socket.
HTH, peadar.
-- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844
smime.p7s
Description: S/MIME Cryptographic Signature
