1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
=============
Version 4.8.0
=============
Version 4.8.0 of mod_wsgi can be obtained from:
https://codeload.github.com/GrahamDumpleton/mod_wsgi/tar.gz/4.8.0
Bugs Fixed
----------
* Fixed potential for process crash on Apache startup when the WSGI script
file or other Python script file were being preloaded. This was triggered
when ``WSGIImportScript`` was used, or if ``WSGIScriptAlias`` or
``WSGIScriptAliasMatch`` were used and both the ``process-group`` and
``application-group`` options were used with those directives.
The potential for this problem arising was extremely high on Alpine Linux,
but seem to be very rare on a full Linux of macOS distribution where glibc
was being used.
* Include a potential workaround so that virtual environment work on Windows.
Use of virtual environments in embedded systems on Windows has been broken
ever since ``python -m venv`` was introduced.
Initially ``virtualenv`` was not affected, although when it changed to
use the new style Python virtual environment layout the same as
``python -m venv`` it also broke. This was with the introduction of about
``virtualenv`` version 20.0.0.
The underlying cause is lack of support for using virtual environments in
CPython for the new style virtual environments. The bug has existed in
CPython since back in 2014 and has not been fixed. For details of the
issue see https://bugs.python.org/issue22213.
For non Window systems a workaround had been used to resolve the problem,
but the same workaround has never worked on Windows. The change in this
version tries a different workaround for Windows environments.
* Added a workaround for the fact that Python doesn't actually set the
``_main_thread`` attribute of the ``threading`` module to the main thread
which initialized the main interpreter or sub interpreter, but the first
thread that imports the ``threading`` module. In an embedded system such
as mod_wsgi it could be a request thread, not the main thread, that would
import the ``threading`` module.
This issue was causing the ``asgiref`` module used in Django to fail when
using ``signal.set_wakeup_fd()`` as code was thinking it was in the main
thread when it wasn't. See https://github.com/django/asgiref/issues/143.
* Using ``WSGILazyInitialization Off`` would cause Python to abort the
Apache parent process. The issue has been resolved, but you are warned
that you should not be using this option anyway as it is dangerous and
opens up security holes with the potential for user code to run as the
``root`` user when Python is initialized.
* Fix a Python deprecation warning for ``PyArg_ParseTuple()`` which would
cause the process to crash when deprecation warnings were turned on
globally for an application. Crash was occuring whenever anything was
output to Apache error log via ``print()``.
Features Changed
----------------
* The ``--isatty`` option of mod_wsgi-express has been removed and the
behaviour enabled by the option is now the default. The default behaviour
is now that if mod_wsgi-express is run in an interactive terminal, then
Apache will be started within a sub process of the mod_wsgi-express script
and the ``SIGWINCH`` signal will be blocked and not passed through to
Apache. This means that a window resizing event will no longer cause
mod_wsgi-express to shutdown unexpectedly.
* When trying to set resource limits and they can't be set, the system error
number will now be included in the error message.
New Features
------------
* Added the ``mod_wsgi.subscribe_shutdown()`` function for registering a
callback to be called when the process is being shutdown. This is needed
because ``atexit.register()`` doesn't work as required for the main
Python interpreter, specifically the ``atexit`` callback isn't called
before the main interpreter thread attempts to wait on threads on
shutdown, thus preventing one from shutting down daemon threads and
waiting on them.
This feature to get a callback on process shutdown was previously
available by using ``mod_wsgi.subscribe_events()``, but that would also
reports events to the callback on requests as they happen, thus adding
extra overhead if not using the request events. The new registration
function can thus be used where only interested in the event for the
process being shutdown.
* Added an ``--embedded-mode`` option to mod_wsgi-express to make it easier
to force it into embedded mode for high throughput, CPU bound applications
with minimal response times. In this case the number of Apache child
worker processes used for embedded mode will be dictated by the
``--processes`` and ``--threads`` option, completely overriding any
automatic mechanism to set those parameters. Any auto scaling done by
Apache for the child worker processes will also be disabled.
This gives preference to using Apache worker MPM instead of event MPM,
as event MPM doesn't work correctly when told to run with less than
three threads per process. You can switch back to using event MPM by
using the ``--server-mpm`` option, but will need to ensure that have
three threads per process or more.
* Locking of the Python global interpreter lock has been reviewed with
changes resulting in a reduction in overhead, or otherwise changing
the interaction between threads such that at high request rate with a
hello world application, a greater request throughput can be achieved.
How much improvement you see with your own applications will depend on
what your application does and whether you have short response times
to begin with. If you have an I/O bound application with long response
times you likely aren't going to see any difference.
* Internal metrics collection has been improved with additional information
provided in process metrics and a new request metrics feature added
giving access to aggregrated metrics over the time of a reporting period.
This includes bucketed time data on requests so can calculate distribution
of server, queue and application time.
Note that the new request metrics is still a work in progress and may be
modified or enhanced, causing breaking changes in the format of data
returned.
* Hidden experimental support for running ``mod_wsgi-express start-server``
on Windows. It will not show in list of sub commands ``mod_wsgi-express``
accepts on Windows, but it is there. There are still various issues that
need to be sorted out but need assistance from someone who knows more
about programming Python on Windows and Windows programming in general to
get it all working properly. If you are interested in helping, reach out
on the mod_wsgi mailing list.
|
