Hi Roberto and all,
We've been using uWSGI for a while and are very pleased with it. We use it
as an nginx upstream and it spawns and calls django processes.
In our site, we have some long encoding process and lately we've decided to
do it asynchronously without blocking the POST request.
To implement that logic we've tried to use the grunt function, have the
child do the processing in background, and the parent to return a normal
HTTP 200 response.
The code we've used goes along the line of:
def long_view(request):
if not uwsgi.grunt():
logging.info("Forked upload processing")
return HttpResponse(json.dumps(dict(success=True)))
# From here on, we're in a detached process
uwsgi.disconnect()
try:
doLongProcessing()
doLongProcessing2()
finally:
os._exit(os.EX_OK)
That code didn't work to well and we got some "writev(): Bad file
descriptor..." errors. Looking at the code I figured that grunt closes the
parent connection thus not letting it to respond to the client. The
following code removes this restriction and let the user the ability to
choose on which process (parent/child) they want to write to back to client
and on the other one they can call uwsgi.disconnect().
diff -ru uwsgi-0.9.7.2/plugins/python/uwsgi_pymodule.c
uwsgi-0.9.7.2-new/plugins/python/uwsgi_pymodule.c
--- uwsgi-0.9.7.2/plugins/python/uwsgi_pymodule.c 2011-04-06
10:50:01.000000000 +0300
+++ uwsgi-0.9.7.2-new/plugins/python/uwsgi_pymodule.c 2011-05-22
17:23:52.000000000 +0300
@@ -2182,7 +2182,6 @@
pid_t grunt_pid;
int i;
- struct wsgi_request *wsgi_req = current_wsgi_req();
if (uwsgi.grunt) {
uwsgi_log("spawning a grunt from worker %d (pid :%d)...\n",
uwsgi.mywid, uwsgi.mypid);
@@ -2218,10 +2217,6 @@
return Py_True;
}
- // close connection on the worker
- fclose(wsgi_req->async_post);
- wsgi_req->fd_closed = 1;
-
clear:
Py_INCREF(Py_None);
return Py_None;
I wanted to share this patch and to understand whether it is the right way
to accomplish what we've been trying to do.
- Alon.
Audish - discover your talent.
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
