From: Rich Bowen Date: Sun, 11 Jun 2006 15:34:12 +0000 (+0000) Subject: emove an appendix that hasn't really been useful since the turn of the X-Git-Tag: 2.3.0~2345 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3c195da01ca416c1d10f993143f3b8b8a2cc1df6;p=thirdparty%2Fapache%2Fhttpd.git emove an appendix that hasn't really been useful since the turn of the century. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@413464 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/stopping.html.en b/docs/manual/stopping.html.en index 888726ca639..397be11ae3e 100644 --- a/docs/manual/stopping.html.en +++ b/docs/manual/stopping.html.en @@ -37,7 +37,6 @@
  • Graceful Restart
  • Restart Now
  • Graceful Stop
    • -
  • Appendix: signals and race conditions

    • See also

    top
    @@ -221,42 +220,6 @@ syntax error(s).
    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  | diff --git a/docs/manual/stopping.xml b/docs/manual/stopping.xml index 71822fd4870..814c89c770f 100644 --- a/docs/manual/stopping.xml +++ b/docs/manual/stopping.xml @@ -228,43 +228,4 @@ syntax error(s). 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.

    -
    -