Description

The version of uWSGI in the Ubuntu/Debian apt repositories (1.0.3) doesn't call close on the wsgi application, this in turn causes the request_finished signal to never fire resulting in open database connections.

According to ​this blogpost uWSGI >= 1.2.6 should be the first version of uWSGI that supports the expected behavior. But the same blogpost warns about other wsgi middleware potentially misbehaving.

I'm wondering why Django < 1.5 didn't show this behavior and what the best course for Django regarding this issue is.

Should there be a warning in the docs about the minimum required uWSGI version? Or should the previous behavior be restored somehow?

Oldest firstNewest firstThreaded

Comments only

Change History (17)

This is a bug in uWSGI, I've hit it in production too. Thanks for filing this ticket.

Django < 1.5 didn't exhibit this behavior because it closed the database connection earlier. But code could reopen the connection later on, before the end of the request, in the case of streaming responses. That was a bug, I fixed it, and I still think it's the right thing to do.

Since Django 1.5 provides explicit support for streaming responses, the closing of the database connection must be performed after the content is fully sent, ie. in close().

I think the best we can do is document this bug of uWSGI in the deployment docs and in the 1.5 release notes.

When a view returns a streaming response, this signal is sent only after the entire response is consumed by the client (strictly speaking, by the WSGI gateway).

If I'm understanding correctly this is not entirely true. This behavior occurs regardless of a streaming response, but was implemented to facilitate streaming responses. Going to slightly alter that note as well.