Return-Path: Delivered-To: apmail-httpd-cvs-archive@www.apache.org Received: (qmail 28833 invoked from network); 11 Jun 2006 14:27:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 11 Jun 2006 14:27:13 -0000 Received: (qmail 58758 invoked by uid 500); 11 Jun 2006 14:27:12 -0000 Delivered-To: apmail-httpd-cvs-archive@httpd.apache.org Received: (qmail 58702 invoked by uid 500); 11 Jun 2006 14:27:12 -0000 Mailing-List: contact cvs-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list cvs@httpd.apache.org Received: (qmail 58688 invoked by uid 99); 11 Jun 2006 14:27:12 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Jun 2006 07:27:12 -0700 X-ASF-Spam-Status: No, hits=-9.4 required=10.0 tests=ALL_TRUSTED,NO_REAL_NAME X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [140.211.166.113] (HELO eris.apache.org) (140.211.166.113) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Jun 2006 07:27:11 -0700 Received: by eris.apache.org (Postfix, from userid 65534) id 1A8931A983A; Sun, 11 Jun 2006 07:26:51 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r413452 - in /httpd/httpd/branches/2.2.x/docs/manual: stopping.html.en stopping.xml Date: Sun, 11 Jun 2006 14:26:50 -0000 To: cvs@httpd.apache.org From: rbowen@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20060611142651.1A8931A983A@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Author: rbowen Date: Sun Jun 11 07:26:50 2006 New Revision: 413452 URL: http://svn.apache.org/viewvc?rev=413452&view=rev Log: Remove an appendix that hasn't really been useful since the turn of the century. Modified: httpd/httpd/branches/2.2.x/docs/manual/stopping.html.en httpd/httpd/branches/2.2.x/docs/manual/stopping.xml Modified: httpd/httpd/branches/2.2.x/docs/manual/stopping.html.en URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/docs/manual/stopping.html.en?rev=413452&r1=413451&r2=413452&view=diff ============================================================================== --- httpd/httpd/branches/2.2.x/docs/manual/stopping.html.en (original) +++ httpd/httpd/branches/2.2.x/docs/manual/stopping.html.en Sun Jun 11 07:26:50 2006 @@ -37,7 +37,6 @@
  • Graceful Restart
  • Restart Now
  • Graceful Stop
  • -
  • Appendix: signals and race conditions
  • See also

    top
    @@ -220,42 +219,6 @@ using rotatelogs style piped logging. Multiple running instances of rotatelogs attempting to rotate the same logfiles at the same time may destroy each other's logfiles.

    -
    top
    -
    -

    Appendix: signals and race conditions

    - -

    Prior to Apache 1.2b9 there were several race - conditions involving the restart and die signals (a simply put, - a race condition is a time-sensitive problem - if something happens - at just the wrong time or things happen in the wrong order, - undesired behaviour will result. If the same thing happens at the right - time, all will be well). For those architectures that have the "right" - feature set we have eliminated as many as we can. But it should - be noted that race conditions do still exist on certain - architectures.

    - -

    Architectures that use an on-disk ScoreBoardFile can potentially have - their scoreboards corrupted. This can result in the "bind: - Address already in use" (after HUP) or "long lost - child came home!" (after USR1). The former is a fatal - error, while the latter just causes the server to lose a - scoreboard slot. So it may be advisable to use graceful - restarts, with an occasional hard restart. These problems are very - difficult to work around, but fortunately most architectures do - not require a scoreboard file. See the ScoreBoardFile documentation for - architecture which uses it.

    - -

    All architectures have a small race condition in each child - involving the second and subsequent requests on a persistent - HTTP connection (KeepAlive). It may exit after reading the - request line but before reading any of the request headers. - There is a fix that was discovered too late to make 1.2. In - theory this isn't an issue because the KeepAlive client has to - expect these events because of network latencies and server - timeouts. In practice it doesn't seem to affect anything either - -- in a test case the server was restarted twenty times per - second and clients successfully browsed the site without - getting broken images or empty documents.

    Available Languages:  de  | Modified: httpd/httpd/branches/2.2.x/docs/manual/stopping.xml URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/docs/manual/stopping.xml?rev=413452&r1=413451&r2=413452&view=diff ============================================================================== --- httpd/httpd/branches/2.2.x/docs/manual/stopping.xml (original) +++ httpd/httpd/branches/2.2.x/docs/manual/stopping.xml Sun Jun 11 07:26:50 2006 @@ -226,43 +226,4 @@ logfiles at the same time may destroy each other's logfiles.

    - -
    Appendix: signals and race conditions - -

    Prior to Apache 1.2b9 there were several race - conditions involving the restart and die signals (a simply put, - a race condition is a time-sensitive problem - if something happens - at just the wrong time or things happen in the wrong order, - undesired behaviour will result. If the same thing happens at the right - time, all will be well). For those architectures that have the "right" - feature set we have eliminated as many as we can. But it should - be noted that race conditions do still exist on certain - architectures.

    - -

    Architectures that use an on-disk ScoreBoardFile can potentially have - their scoreboards corrupted. This can result in the "bind: - Address already in use" (after HUP) or "long lost - child came home!" (after USR1). The former is a fatal - error, while the latter just causes the server to lose a - scoreboard slot. So it may be advisable to use graceful - restarts, with an occasional hard restart. These problems are very - difficult to work around, but fortunately most architectures do - not require a scoreboard file. See the ScoreBoardFile documentation for - architecture which uses it.

    - -

    All architectures have a small race condition in each child - involving the second and subsequent requests on a persistent - HTTP connection (KeepAlive). It may exit after reading the - request line but before reading any of the request headers. - There is a fix that was discovered too late to make 1.2. In - theory this isn't an issue because the KeepAlive client has to - expect these events because of network latencies and server - timeouts. In practice it doesn't seem to affect anything either - -- in a test case the server was restarted twenty times per - second and clients successfully browsed the site without - getting broken images or empty documents.

    -
    -