Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Warn that `request_finished` is not sent under certain conditions #1238

Closed
wants to merge 1 commit into from

3 participants

@jaap3

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.

Trac ticket: 20537

Jaap Roes Warn that `request_finished` is not sent under certain conditions
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.

Trac ticket: 20537
996e80e
@timgraham timgraham commented on the diff
docs/howto/deployment/wsgi/index.txt
@@ -82,6 +82,16 @@ 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::
+
+ There's WSGI middleware out there that does not call ``close`` on the
@timgraham Owner

"There's WSGI middleware out there that" -> "Some third-party WSGI middleware do not"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@aaugustin
Owner

Merged in 3ce1d30, thank you.

@aaugustin aaugustin closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jun 3, 2013
  1. Warn that `request_finished` is not sent under certain conditions

    Jaap Roes authored
    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.
    
    Trac ticket: 20537
This page is out of date. Refresh to see the latest.
View
10 docs/howto/deployment/wsgi/index.txt
@@ -82,6 +82,16 @@ 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::
+
+ There's WSGI middleware out there that does not call ``close`` on the
@timgraham Owner

"There's WSGI middleware out there that" -> "Some third-party WSGI middleware do not"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+ 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
+ never triggers. This can result in idle connections to database and
+ memcache servers.
+
Upgrading from Django < 1.4
---------------------------
View
9 docs/howto/deployment/wsgi/uwsgi.txt
@@ -34,6 +34,15 @@ command. For example:
.. _installation procedures: http://projects.unbit.it/uwsgi/wiki/Install
+.. warning::
+
+ Some distributions (most notably Ubuntu) ship an outdated version of
+ uWSGI that does not conform to the the WSGI specification. Versions
+ prior to 1.2.6 do not always call ``close`` on the response object
+ after handling a request. In those cases the
+ :data:`~django.core.signals.request_finished` signal never triggers.
+ This can result in idle connections to database and memcache servers.
+
uWSGI model
-----------
View
19 docs/ref/signals.txt
@@ -451,17 +451,20 @@ request_finished
Sent when Django finishes processing an HTTP request.
-.. note::
+.. versionchanged:: 1.5
- When a view returns a :ref:`streaming response <httpresponse-streaming>`,
- this signal is sent only after the entire response is consumed by the
- client (strictly speaking, by the WSGI gateway).
+ Before Django 1.5, this signal was sent before delivering content to
+ the client. In order to accommodate
+ :ref:`streaming responses <httpresponse-streaming>`, it is now sent
+ after the response has been fully delivered to the client.
-.. versionchanged:: 1.5
+.. note::
- Before Django 1.5, this signal was fired before sending the content to the
- client. In order to accomodate streaming responses, it is now fired after
- sending the content.
+ Some WSGI servers and middleware do not always call ``close`` on the
+ response object after handling a request (most notably uWSGI prior to
+ 1.2.6 and Sentry's error reporting middleware up to 2.0.7). In those cases
+ this signal is no sent at all. This can result in idle connections to
+ database and memcache servers.
Arguments sent with this signal:
View
10 docs/releases/1.5.txt
@@ -440,7 +440,15 @@ generation.
This signal is now sent after the content is fully consumed by the WSGI
gateway. This might be backwards incompatible if you rely on the signal being
fired before sending the response content to the client. If you do, you should
-consider using a middleware instead.
+consider using :doc:`middleware </topics/http/middleware>`. instead.
+
+.. note::
+
+ Some WSGI servers and middleware do not always call ``close`` on the
+ response object after handling a request (most notably uWSGI prior to
+ 1.2.6 and Sentry's error reporting middleware up to 2.0.7). In those cases
+ the ``request_finished`` signal never triggers. This can result in idle
+ connections to database and memcache servers.
OPTIONS, PUT and DELETE requests in the test client
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Something went wrong with that request. Please try again.