diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/release-notes.rst | 1 | ||||
| -rw-r--r-- | docs/release-notes/version-4.5.6.rst | 61 |
2 files changed, 62 insertions, 0 deletions
diff --git a/docs/release-notes.rst b/docs/release-notes.rst index cf04560..22d5eb5 100644 --- a/docs/release-notes.rst +++ b/docs/release-notes.rst @@ -5,6 +5,7 @@ Release Notes .. toctree:: :maxdepth: 2 + release-notes/version-4.5.6 release-notes/version-4.5.5 release-notes/version-4.5.4 release-notes/version-4.5.3 diff --git a/docs/release-notes/version-4.5.6.rst b/docs/release-notes/version-4.5.6.rst new file mode 100644 index 0000000..8183eb3 --- /dev/null +++ b/docs/release-notes/version-4.5.6.rst @@ -0,0 +1,61 @@ +============= +Version 4.5.6 +============= + +Version 4.5.6 of mod_wsgi can be obtained from: + + https://codeload.github.com/GrahamDumpleton/mod_wsgi/tar.gz/4.5.6 + +Bugs Fixed +---------- + +1. Reinstanted change to associate any messages logged via ``sys.stdout`` + and ``sys.stderr`` back to the request so that Apache can log them + with the correct request log ID. This change was added in 4.5.4, but + was reverted in 4.5.5 as the change was causing process crashes under + Python 3. + +2. When using Apache 2.4 use new style ``Require`` directive instead of + older ``Order`` and ``Allow`` when setting up access controls for + ``mod_wsgi-express``. This fixes a problem where when using + ``--include-file`` and ``Require`` directive was being used. Precedence + order was such that older directives were overriding new directive and + it was possible to permit access to additional directories when using + custom configuration. + +3. Django 1.10 requires that management commands use argparse style + options but ``mod_wsgi-express`` uses optparse style options. Can no + longer simply merge main script option list to get management command + option list. Instead need to convert optparse list to argparse format on + the fly, as still need to retain main script option list as optparse + until drop Python 2.6 support. Changes stop ``runmodwsgi`` management + command failing when using Django 1.10+. + +New Features +------------ + +1. Added ``startup-timeout`` option to ``WSGIDaemonProcess`` directive. + If set and the first loading of the WSGI application script file + fails, then if no subsequent attempt to load it succeeds within the + specified startup timeout, the daemon process will be restarted. When + configuring mod_wsgi directly, the option is not enabled by default. + The option is exposed via ``mod_wsgi-express`` with a default value + of 15 seconds. + + This would be used where running the Django web framework and there is + a risk of the database not being available, causing Django initialisation + to fail. Django doesn't allow initialisation to be performed a second + time in the same process, meaning it will then constantly fail. Use of + startup timeout will allow the process to be restarted in face of such + constant startup failures. If the database is available when the + process is restarted, then next time the process starts, everything + should be fine. + + Do note that this option should preferably only be used where the one + WSGI application has been delegated to a WSGI daemon process. This is + because if multiple WSGI applications are hosted out of the daemon + process group, be they in the same application group or distinct ones, + as soon as any one of them loads successfully, then the startup timeout + is disabled, meaning that if a subsequent one loaded is constantly + failing, then a process restart will not occur. Best practice is to + delegate each WSGI application to a distinct daemon process group. |