cvs commit: apachen/htdocs/manual/misc fin_wait_2.html

1998-01-26 Thread brian
brian   98/01/25 22:58:32

  Modified:htdocs/manual/misc fin_wait_2.html
  Log:
  If SCO's going to break their links, I'm not going to go searching for where 
they
  moved it to.
  
  Cold and rainy and dark.
  
  Revision  ChangesPath
  1.13  +0 -3  apachen/htdocs/manual/misc/fin_wait_2.html
  
  Index: fin_wait_2.html
  ===
  RCS file: /export/home/cvs/apachen/htdocs/manual/misc/fin_wait_2.html,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- fin_wait_2.html   1997/09/07 03:10:58 1.12
  +++ fin_wait_2.html   1998/01/26 06:58:31 1.13
  @@ -165,9 +165,6 @@
   modify CODEtcp_fin_wait_2_flush_interval/CODE, but the
   default should be appropriate for most servers and improper
   tuning can have negative impacts.
  -LIA HREF=http://www.sco.com/;SCO TCP/IP Release 1.2.1/A
  -can be modified to have a timeout by following
  -A 
HREF=http://www.sco.com/cgi-bin/waisgate?WAISdocID=2242622956+0+0+0WAISaction=retrieve;
 SCO's instructions/A.
   LIA HREF=http://www.linux.org/;Linux/A 2.0.x and
   earlier(?)
   LIA HREF=http://www.hp.com/;HP-UX/A 10.x defaults to
  
  
  


cvs commit: apachen/htdocs/manual/misc fin_wait_2.html

1997-09-06 Thread Marc Slemko
marc97/09/06 20:10:59

  Modified:htdocs/manual/misc fin_wait_2.html
  Log:
  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.
  
  Revision  ChangesPath
  1.12  +12 -13apachen/htdocs/manual/misc/fin_wait_2.html
  
  Index: fin_wait_2.html
  ===
  RCS file: /export/home/cvs/apachen/htdocs/manual/misc/fin_wait_2.html,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- fin_wait_2.html   1997/08/17 05:55:54 1.11
  +++ fin_wait_2.html   1997/09/07 03:10:58 1.12
  @@ -43,8 +43,8 @@
   
   LIH2But why does it happen?/H2
   
  -There are several reasons for it happening, and not all of them are
  -fully understood by the Apache team yet.  What is known follows.P
  +There are numerous reasons for it happening, some of them may not
  +yet be fully clear.  What is known follows.P
   
   H3Buggy clients and persistent connections/H3
   
  @@ -111,15 +111,14 @@
   all servers that support persistent connections, including Apache 1.1.x
   and 1.2.P
   
  -H3Something in Apache may be broken/H3
  +H3A necessary bit of code introduced in 1.2/H3
   
   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.P
  +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 CODElingering_close()/CODE 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 @@
   the connection has closed.
   See the A HREF=#appendixappendix/A for more details.P
   
  -We have not yet tracked down the exact reason why
  -CODElingering_close()/CODE 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.P
  +The code in CODElingering_close()/CODE 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 CODElingering_close/CODE
  +code that causes the observed problems.P
   
   H2LIWhat can I do about it?/H2