Managing Django handler's thread

Question

Is it a webserver spawning/controlling a thread(process) which calls request handler? Or is there any asynchronous/multithreaded architecture in Django itself? The problem is that when an (ajax) request is being processed for a long time, and during this client re-sends it again, the previous handler gets terminated. I would like to have some control over this: e.g. perform some cleanup actions. Or terminate the handler manually in some cases.

Answer 1

Django is not a web server, it's a web framework, so indeed as you said, it spawns threads to handle incoming requests, but it's the web sever's job to accept and finally respond to [http(s)] requests of the users.

So what you're facing is probably that the computation takes too much time and the web server, most probably nginx or apache, timeouts the request. In order to prevent timeouts, you need to increase the timeout setting in your web server.

Also in order to get Django to work, you need a connector that understands WSGI, for this people mostly use the likes of gunicorn, uwsgi, mod_wsgi and so on. You need to also configure them to accept longer values to timeout.

For example, if you're using Nginx/Gunicorn, you can refer to this question to see how you'd go about setting the timeouts.

Finally, as a final note, if you're doing large computations on requests, it's better not to block the user's request and do it in the background. Celery is an incredibly handy tool to look at in this situations.

In your case, if it's not a huge computation, you can simply increase the timeout value. But in case your computation might take long times, say 45+ seconds, it's better to change the way you do things and implement a solution using celery and background processing of requests.

Edit.

In case you want to know who exactly handles threads and what's going on behind the scenes, I encourage you to read this posting about Gunicorn since it's good insight on how things work. Also it's good to read on the design page of Gunicorn itself before reading that. Basically both the WSGI program and the WebServer would kill the thread in case of a timeout.

If your django threads timeout sooner (gunicorn timeout), then the WSGI program kills the thread. If on the other hand gunicorn's timeout is set higher than that of Nginx, Nginx would kill the thread.