[1.5.x] Warned that request_finished isn't sent by some buggy setups.

Older versions of uWSGI and Sentry's middleware do not adhere to
the WSGI spec and cause the `request_finished` signal to never
fire. Added notes to the appropriate places in the docs.

Fixed #20537.

Backport of 3ce1d30.

Conflicts:
	docs/howto/deployment/wsgi/index.txt
This commit is contained in:
Jaap Roes 2013-06-03 15:53:04 +02:00 committed by Aymeric Augustin
parent b75f1f3d27
commit 60353458ae
4 changed files with 38 additions and 10 deletions

View file

@ -71,3 +71,11 @@ application that later delegates to the Django WSGI application, if you want to
combine a Django application with a WSGI application of another framework.
.. _`WSGI middleware`: http://www.python.org/dev/peps/pep-3333/#middleware-components-that-play-both-sides
.. note::
Some third-party WSGI middleware do not call ``close`` on the response
object after handling a request — most notably Sentry's error reporting
middleware up to version 2.0.7. In those cases the
:data:`~django.core.signals.request_finished` signal isn't sent. This can
result in idle connections to database and memcache servers.

View file

@ -34,6 +34,15 @@ command. For example:
.. _installation procedures: http://projects.unbit.it/uwsgi/wiki/Install
.. warning::
Some distributions, including Debian and Ubuntu, ship an outdated version
of uWSGI that does not conform to the WSGI specification. Versions prior to
1.2.6 do not call ``close`` on the response object after handling a
request. In those cases the :data:`~django.core.signals.request_finished`
signal isn't sent. This can result in idle connections to database and
memcache servers.
uWSGI model
-----------