httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <>
Subject Re: general/3289: repeated connects kill the server (fwd)
Date Mon, 26 Oct 1998 09:43:58 GMT

Hmm; when trying this from an NT box with a serial wire connected to it
rather than a ethernetcard, it seems to me that it is the NT's stack which
gets overwhelmed. I get a 'dead' server apperanve on NT, but the actual
server still lives on. (Server is just Apache 1.2 on a x486 freebsd 2.1
box). I cannot quite reproduce using the network card. My gues would be
that due to latency, whatever, the handshake takes to long on the modem
link, it needs bits of buffers kept, and finally fills some crucial

Perhaps the poster could check if the server is really down; and/or if for
example 'telnet' to that same machine also shows it as being down. And/or
if a reboot of the NT stations makes the server seemingly 'unhang' after
having seemingly 'hung' it.

Needless to say, a good max # per time-period per host would be a good
thing. Even if it was per child (otherwise you would have to hash through
a scoreboard accumulative structure).


On Sun, 25 Oct 1998, Marc Slemko wrote:

> I find their excuse about posting this anonymously horribly lame.  I don't
> want to see them keep opening the same PR over and over and over just to
> be a pain because they have some hangup about giving their address or
> getting an account at one of 3842 free email services.
> As to their problem, it seems obvious that NT/Navigator is broken and will
> just keep opening connections.  There are lots of ways to do a similar
> thing.  While I still think a general limit connections per host patch
> should be in Apache, I really don't think this particular thing is too
> worty of much attention.
> ---------- Forwarded message ----------
> Date: 25 Oct 1998 15:42:12 -0000
> From: Anonymous <>
> To:
> Subject: general/3289: repeated connects kill the server
> >Number:         3289
> >Category:       general
> >Synopsis:       repeated connects kill the server
> >Confidential:   no
> >Severity:       critical
> >Priority:       medium
> >Responsible:    apache
> >State:          open
> >Class:          sw-bug
> >Submitter-Id:   apache
> >Arrival-Date:   Sun Oct 25 07:50:00 PST 1998
> >Last-Modified:
> >Originator:
> >Organization:
> apache
> >Release:        1.3.2
> >Environment:
> Apache 1.3.2 server running on a Linux 2.0.35 kernel
> >Description:
> I'm posting this anonymously cause I don't care to take credit for discovering
> this weekness.  You can choose to close this bug out too without investigating
> it like the last time I reported it.  Yall can either fix the bug before the
> whole world knows about it, or wait till the whole world knows and then fix it.
> And yes the last time the bug was submitted it had PLENTY of information on 
> how to reproduce it.  So once again.... read the next section carefully.
> >How-To-Repeat:
> Run Netscape 4.0 on a Windows NT 4.0 workstation connected to the internet by a 
> modem (56K).  Load a web site with Netscape that is running off Apache.  Then 
> hold down the CTRL-R (Reload) key (hold down the keyboard key, don't click 
> toolbar button). Hold down the key for approximately one plus minute. Netscape 
> will attempt to reload this page over and over and over again at an extremely 
> high rate of speed.  Typically the send/recv lights both blink rapidly for a 
> while... then the server stops responding completely.  It doesn't kill the 
> machine because FTP and other TCP and UDP based protocols still function just 
> fine on the server.  Depending on factors yet unknown (strength of the web 
> server box, etc.) it may recover from this after a while or simply never recover  
> at all.
> >Fix:
> Don't close out the bug before giving it a valid review.  
> >Audit-Trail:
> >Unformatted:
> [In order for any reply to be added to the PR database, ]
> [you need to include <apbugs@Apache.Org> in the Cc line ]
> [and leave the subject line UNCHANGED.  This is not done]
> [automatically because of the potential for mail loops. ]
> [If you do not include this Cc, your reply may be ig-   ]
> [nored unless you are responding to an explicit request ]
> [from a developer.                                      ]
> [Reply only with text; DO NOT SEND ATTACHMENTS!         ]

View raw message