Date: Tue, 1 Apr 1997 18:39:30 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: Renaud Waldura <rw@softway.com> Cc: freebsd-isp@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Apache lingering_close error Message-ID: <Pine.BSF.3.95.970401182910.8420D-100000@alive.znep.com> In-Reply-To: <199704012328.PAA15669@softway95.softway.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Apr 1997, Renaud Waldura wrote: > > I'm using Apache 1.2b7. With the proxy module, I got lots of errors: > > [Fri Mar 28 22:42:11 1997] shutdown: Invalid argument > [Fri Mar 28 22:42:11 1997] - lingering_close > > until I added > > EXTRA_CFLAGS=-DUSE_SO_LINGER -DNO_LINGCLOSE > > in the Configuration file. > > It works fine now, although the documentation > http://www.apache.org/docs/misc/fin_wait_2.html > makes me wonder if this was the Right Thing To Do. > > It says that FreeBSD 2.1 implements correctly the FIN_WAIT_2 timeout, > but does this mean that SO_LINGER is ok too? There is no reason to disable linging_close for FreeBSD[1]. The message is simply a combination between a warning and a not-yet-removed debugging message; most of the time it pops up simply due to a race condition in the code path; there are a couple of additional issues when using it with the proxy code that I haven't had time to follow, but nothing that hurts more than outputting that message sometimes. It should not hurt anything. We are having some trouble with the lingering_close function (which is why I wrote the above web page...) and are still playing around with a few things. I don't really want to comment on the SO_LINGER part other than to say that you should just use lingering_close in FreeBSD. [1] That is a lie. There are some performance issues that come up when using lingering_close (ie. child processes potentially hang around finishing up a request for longer), but SO_LINGER potentially has even more performance problems. What we really need is a better API, but lacking that lingering_close is the best solution[2]. It _IS_ necessary. [2] For now. This whole issue will go away in 2.0 because then the only overhead will be keeping the socket over, since 2.0 will threaded so the cleanup doesn't have to block a whole process.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970401182910.8420D-100000>