#29069: Static file serving does not call request_finished signal
-------------------------------------+-------------------------------------
Reporter: André Cruz | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.11
Severity: Normal | Resolution:
Keywords: streamingresponse | Triage Stage: Accepted
request_finished |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Matt Hoskins):
I just hit this as well - on my dev server, with quite a few test
instances running under runserver, I hit a postgres server connection
limit. I noticed that if I did multiple static file requests in a row
(without accessing a normal django view) I would get a new idle connection
left after each static connection. If I then did a normal django view
access it would seem to clear out most of those idle connections.
In trying to figure out what was going on I also discovered (like Tom)
that the issue was that request_finished wasn't being triggered for static
file serving because of the reasons set out by Tom
(wsgiref.util.FileWrapper being returned) and thus
django.db.close_old_connections isn't being triggered at the end of
handling a static file request.
(I'm not sure why the normal django view access clears up the idle
connections - perhaps it's just as a result of some python garbage
collection going off which isn't otherwise happening just when static file
requests are being processed).
The suggested PR only helps when using the django provided http server. If
you use a third party web server that provides wsgi.file_wrapper then
you'll still have the issue that for FileResponse responses they'll get
converted to file_wrapper from that third party web server and thus the
standard django response close handling won't be called.
One solution is of course to not do that conversion to wsgi.file_wrapper
at all - however the downside of that is of course that you're not taking
advantage of the web server's offered performance option of
wsgi.file_wrapper. Would it be a workable option to wrap
response.file_to_stream to pass into wsgi.file_wrapper in a way that means
the standard django response close handling can be hooked (the PEP on
wsgi.file_wrapper does talk about the requirement for close methods on the
passed object and its iterable)? If it's not viable, then it may just need
to be the case that when WSGIHandler makes use of wsgi.file_wrapper it at
least then calls django.db.close_old_connections after doing the wrapping
to try clear up connections.
--
Ticket URL: <https://code.djangoproject.com/ticket/29069#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.89fe586bc4f99c6535426fa6dfa6675d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
