Hi all,
Utter uwsgi newbie here. I'm running a uwsgi server in a JSON RPC client
server architecture. Some of the calls can take a few minutes to
complete, and the problem I'm having is that the client and server lose
their connection after about a minute. The server continues to process
the data for another 30s to a minute, writes the data to another server,
and then gets a broken pipe when trying to write to the client. When I
run the application with wsgiref.simple_server.make_server everything
works correctly. Pertinent information is below:
_
uwsgi command line:_
uwsgi --master --processes 20 --cheaper 4 --gevent 5 --http :10001
--wsgi-file [file]
_bottom of the stack trace client side:_
/usr/lib/python2.7/httplib.pyc in _read_status(self)
369 # Presumably, the server closed the connection before
370 # sending a valid response.
--> 371 raise BadStatusLine(line)
372 try:
373 [version, status, reason] = line.split(None, 2)
BadStatusLine: ''
_Error in the server logs/std*:_
SIGPIPE: writing to a closed pipe/socket/fd (probably the client
disconnected) on request / (ip 127.0.0.1) !!!
IOError: write error
[pid: 3138|app: 0|req: 1/1] 127.0.0.1 () {34 vars in 897 bytes} [Fri Feb
15 09:13:15 2013] POST / => generated 0 bytes in 44679 msecs (HTTP/1.1
200) 4 headers in 149 bytes (5 switches on core 4)
Obviously the client and server are on the same machine. I've tried
running with -t at 0 and 300 and without gevent. Looking here:
http://uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html ...the
most pertinent note seems to be:
If an HTTP request has a body (like a POST request generated by
a form), you /have/ to read (consume) it in your application....
The method params are in JSON in the request body, so I presume the body
is being consumed since the method is getting the params.
There's a brief (~5s) CPU spike during the method, usually to around
30-50% per top. Memory, as far as I can tell, never gets above 1%.
It's not clear to me what to do next to figure out why this is happening
- it seems it must be related to the uwsgi container as the wsgiref
container doesn't have this problem. Any advice would be appreciated.
Thanks, Gavin
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
