From 0adb26e9cb344f1e9df42670a3ae1b7228d1b1d4 Mon Sep 17 00:00:00 2001 From: Marc Slemko Date: Sun, 7 Sep 1997 03:10:58 +0000 Subject: [PATCH] Update the fin_wait_2 page to reflect the current understanding of the issues; remove the suggestion that Apache is buggy, since no bugs have been found in that code. It now appears most likely that it is just the result of a bad interaction. The real solution, as always, is still a timeout for FIN_WAIT_2. PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@79161 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/misc/fin_wait_2.html | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/docs/manual/misc/fin_wait_2.html b/docs/manual/misc/fin_wait_2.html index 17fe8e38b3..e0276594bc 100644 --- a/docs/manual/misc/fin_wait_2.html +++ b/docs/manual/misc/fin_wait_2.html @@ -43,8 +43,8 @@ process.

  • But why does it happen?

    -There are several reasons for it happening, and not all of them are -fully understood by the Apache team yet. What is known follows.

    +There are numerous reasons for it happening, some of them may not +yet be fully clear. What is known follows.

    Buggy clients and persistent connections

    @@ -111,15 +111,14 @@ As far as we know, the client-caused FIN_WAIT_2 problem is present for all servers that support persistent connections, including Apache 1.1.x and 1.2.

    -

    Something in Apache may be broken

    +

    A necessary bit of code introduced in 1.2

    While the above bug is a problem, it is not the whole problem. Some users have observed no FIN_WAIT_2 problems with Apache 1.1.x, but with 1.2b enough connections build up in the FIN_WAIT_2 state to -crash their server. We have not yet identified why this would occur -and welcome additional test input.

    +crash their server. -One possible (and most likely) source for additional FIN_WAIT_2 states +The most likely source for additional FIN_WAIT_2 states is a function called lingering_close() which was added between 1.1 and 1.2. This function is necessary for the proper handling of persistent connections and any request which includes @@ -134,13 +133,13 @@ has a chance to read the server's response, and thus understand why the connection has closed. See the appendix for more details.

    -We have not yet tracked down the exact reason why -lingering_close() causes problems. Its code has been -thoroughly reviewed and extensively updated in 1.2b6. It is possible -that there is some problem in the BSD TCP stack which is causing the -observed problems. It is also possible that we fixed it in 1.2b6. -Unfortunately, we have not been able to replicate the problem on our -test servers.

    +The code in lingering_close() appears to cause problems +for a number of factors, including the change in traffic patterns +that it causes. The code has been thoroughly reviewed and we are +not aware of any bugs in it. It is possible that there is some +problem in the BSD TCP stack, aside from the lack of a timeout +for the FIN_WAIT_2 state, exposed by the lingering_close +code that causes the observed problems.

  • What can I do about it?

    • -- 2.50.1