2010/9/10 Roberto De Ioris <[email protected]>:
>
> Client send request -> nginx send request to uWSGI -> uWSGI/app set status
> code (and probably some header) -> client disconnect -> nginx close the
> socket with uWSGI -> uWSGI get broken pipe and a 0 response.
>
> uWSGI never buffer data (by default), it send data asap and stop the
> request at the first error.
Hi Roberto,
There are several signs that make me think I'm not facing client
aborts in this case:
1) haproxy logs mention status flags of prematurely closed
connections, and in all cases I see sH which means server never
completed the http headers. Stating the haproxy configuration
manual[1]:
sH The "timeout server" stroke before the server could return its
response headers. This is the most common anomaly, indicating too
long transactions, probably caused by server or database saturation.
The immediate workaround consists in increasing the "timeout server"
setting, but it is important to keep in mind that the user experience
will suffer from these long response times. The only long term
solution is to fix the application.
2) when client aborts I usually see explicit errors in uwsgi output,
such as this:
SIGPIPE: writing to a closed pipe/socket/fd !!!
write(): Broken pipe [pyutils.c line 101]
In my case there is no error printed.
BTW: it would be great to mention the offending request log line upon
error. I have the -L flag set because I don't want to print all
requests, but only offending requests would be great.
Tell me if you need more information to diagnose this. I can afford
to attach gdb on the production server if needed, provided we can set
a meaningful breakpoint to catch an empty reply, as the problem
happens randomly and cannot be easily reproduced.
Cheers,
--
Jean-Baptiste Quenot
[1] http://haproxy.1wt.eu/download/1.3/doc/configuration.txt
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
