Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Auto-Terminating Long-Running Requests in Django

I've got a setup with Apache + mod_wsgi running django code, and I'd like to add a layer of protection in case a non-terminating view slips in. Something that kills-off a requests exceeding, say, 30 seconds would be ideal.

For testing I've just put a time.sleep(60) in a view.

I've tried the TimeOut 30 setting in Apache, but I still get curl returning after 60 seconds.

I see mod_wsgi itself offers three different time-out values, but none of them seem to apply to a long-running request.

Is there a standard piece of Django middleware for this or is there a knob I'm missing on Apache or mod_wsgi?

like image 462
Ry4an Brase Avatar asked Oct 11 '11 17:10

Ry4an Brase


People also ask

How many concurrent requests can Django handle?

Can Django Handle Multiple Requests at the Same Time? Actually, Django handles only one request at a time.

Can Django handle multiple requests simultaneously?

Django handles just a request at a time. If you use the very old CGI interface (between your web-server and Django), a new Django process is started at every request.

How does Django process requests?

Django uses request and response objects to pass state through the system. When a page is requested, Django creates an HttpRequest object that contains metadata about the request. Then Django loads the appropriate view, passing the HttpRequest as the first argument to the view function.


1 Answers

It is actually really difficult to terminate a single Python request thread in a multithread application. The best you can do is make a decision to shutdown the whole process and restart it. Because such an action will disrupt concurrent requests, you would as a result really need to restrict yourself to a single threaded configuration.

Even then the support in mod_wsgi 3.X isn't ideal for this. There is inactivity-timeout for daemon mode, but it actually causes process to be restarted in two situations. The first is when there are no requests at all and process is idle. The second is when all request threads have blocked and timeout expires.

In mod_wsgi 4.X (in repository trunk at this time), the two concepts have been separated and now inactivity-timeout only applies to completely idle process with no concurrent requests. A new blocked-timeout has been added to separately specific a timeout for when whole process is blocked. It is this latter one you can use.

If you want to learn more about the new option, you will need to go over to the mod_wsgi mailing list to discusss it.

like image 92
Graham Dumpleton Avatar answered Sep 18 '22 11:09

Graham Dumpleton