Received: by taz.hyperreal.com (8.8.3/V2.0) id JAA16552; Tue, 14 Jan 1997 09:51:24 -0800 (PST) Received: from valis.worldgate.com by taz.hyperreal.com (8.8.3/V2.0) with ESMTP id JAA16539; Tue, 14 Jan 1997 09:51:18 -0800 (PST) Received: from localhost (marcs@localhost) by valis.worldgate.com (8.8.4/8.6.12) with SMTP id KAA24209 for ; Tue, 14 Jan 1997 10:51:16 -0700 (MST) Date: Tue, 14 Jan 1997 10:51:15 -0700 (MST) From: Marc Slemko To: new-httpd@hyperreal.com Subject: Re: lingering_close In-Reply-To: <199701141725.LAA20261@sierra.zyzzyva.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com Except that on a number of platforms, people are saying that NO_LINGCLOSE _is_ helping, ie. making the difference between their machines crashing and them staying alive with no problems. Details on what various people are seeing under what conditions to come later... On Tue, 14 Jan 1997, Randy Terbush wrote: > Actually, as I think about this more, I believe that the reason > we are seeing more FIN_WAIT_2 in 1.2 is because we are slamming > the door on timeouts. The whole purpose of lingering_close() was > to work around some of the buggier TCP stacks. This would also > explain why defining NO_LINGCLOSE is not helping the situation. > > > > Then I think we need to be setting timeout_req = NULL. It seems > > that the frequency of calls to lingering_close() with Invalid > > sd are directly related to timeouts. We're longjumping back > > to child_main() and calling lingering_close() there if(r). > > > > > > > Randy Terbush wrote: > > > > > > > > Should we be calling lingering_close() in timeout()? > > > > > > Naah - if we've timed out we don't want to waste even more time trying to > > > deliver stuff to them. > > > > > > Cheers, > > > > > > Ben. > > > > > > -- > > > Ben Laurie Phone: +44 (181) 994 6435 Email: ben@algroup.co.uk > > > Freelance Consultant and Fax: +44 (181) 994 6472 > > > Technical Director URL: http://www.algroup.co.uk/Apache-SSL > > > A.L. Digital Ltd, Apache Group member (http://www.apache.org) > > > London, England. Apache-SSL author > > > > > > >