> > On 10/18/2014 11:40 PM, Roberto De Ioris wrote: >>> Hello all, >>> >>> Hopefully I'm not asking an question that's been answered many times >>> before; I've been unable to find anything via Google. >>> >>> Short version: >>> When I attempt to stream data to a uwsgi server running a JSONRPC >>> application, every other request fails with the error 'Error writing >>> request body to server', even if the data is< 100B. This effect where >>> the first request succeeds, the second fails, third succeeds, etc. is >>> completely reproducible and constant. When I set up the client so that >>> it buffers the request and then sends it all in one piece everything >>> works normally. Also, if I start the server via >>> wsgiref.simple_server.make_server.serve_forever() everything works >>> normally. >>> >>> More details: >>> I'm currently testing with Java code; the error can be toggled on by >>> setting one of >>> http://docs.oracle.com/javase/7/docs/api/java/net/HttpURLConnection.html#setFixedLengthStreamingMode%28int%29 >>> http://docs.oracle.com/javase/7/docs/api/java/net/HttpURLConnection.html#setChunkedStreamingMode%28int%29 >>> >>> Also, putting nginx in front of the server fixes the problem, >>> presumably >>> because nginx buffers the entire request before sending it to uwsgi. >>> >>> Interestingly, if I sleep for at least 5s prior to each request, the >>> problem is resolved. At 4s every second request fails. >>> >>> The uwsgi command line is: >>> uwsgi --master --processes 20 --cheaper 4 \ >>> --http :10000 --http-timeout 600 --pidfile pyservice.pid >>> --daemonize uwsgi.log \ >>> --wsgi-file PyLogServer.py >>> >>> My uwsgi version is pretty old, 1.4.4. Ubuntu is 12.04. >>> >>> Any ideas what might be causing this problem / debugging suggestions? >>> Are there any more details I could provide that might be useful? >>> >>> Thanks, Gavin >>> >>> >> What you mean for "streaming ? >> >> Because if you mean chunked body it is not supported by WSGI specs >> (albeit >> uWSGI has an api for it) > Well... I mean whatever Java does under the hood when I call one of the > two methods linked above. Unfortunately I don't know the exact details, > but it probably is chunking the body. > >> >> Btw, you should post uWSGI logs for both successful requests and failed >> ones. And if you can previde an example client it would help in >> understanding what is going on. > I made a SSCCE: > client: http://pastebin.com/cNFgRMLY > server: http://pastebin.com/y2AYkScy > > client output is: > _______________________ > http://localhost:10000 > 0 > 200 OK > 0123456789 > 1 > java.net.SocketException: Unexpected end of file from server > 2 > 200 OK > 0123456789 > 3 > java.net.SocketException: Unexpected end of file from server > 4 > 200 OK > 0123456789 > 5 > java.net.SocketException: Unexpected end of file from server > Sleep: 0, failures 3/6 > _______________________ > > server logs: > ________________________ > *** Starting uWSGI 1.4.4 (64bit) on [Sun Oct 19 09:50:49 2014] *** > compiled with version: 4.6.3 on 23 January 2013 15:54:59 > os: Linux-3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 > nodename: *snip* > machine: x86_64 > clock source: unix > pcre jit disabled > detected number of CPU cores: 7 > current working directory: *snip* > writing pidfile to pyservice.pid > detected binary path: /usr/local/bin/uwsgi > your processes number limit is 160617 > your memory page size is 4096 bytes > detected max file descriptor number: 10000 > lock engine: pthread robust mutexes > uWSGI http bound on :10000 fd 4 > uwsgi socket 0 bound to TCP address 127.0.0.1:46592 (port auto-assigned) > fd 3 > Python version: 2.7.3 (default, Aug 1 2012, 05:25:23) [GCC 4.6.3] > *** Python threads support is disabled. You can enable it with > --enable-threads *** > Python main interpreter initialized at 0x22e8a80 > your server socket listen backlog is limited to 100 connections > mapped 1520232 bytes (1484 KB) for 20 cores > *** Operational MODE: preforking *** > WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x22e8a80 > pid: 4005 (default app) > *** uWSGI is running in multiple interpreter mode *** > spawned uWSGI master process (pid: 4005) > spawned uWSGI worker 1 (pid: 4006, cores: 1) > spawned uWSGI worker 2 (pid: 4007, cores: 1) > spawned uWSGI worker 3 (pid: 4008, cores: 1) > spawned uWSGI worker 4 (pid: 4009, cores: 1) > spawned uWSGI http 1 (pid: 4010) > [pid: 4009|app: 0|req: 1/1] 127.0.0.1 () {32 vars in 427 bytes} [Sun Oct > 19 09:50:56 2014] POST / => generated 10 bytes in 0 msecs (HTTP/1.1 200) > 1 headers in 39 bytes (1 switches on core 0) > [pid: 4008|app: 0|req: 1/2] 127.0.0.1 () {32 vars in 427 bytes} [Sun Oct > 19 09:50:56 2014] POST / => generated 10 bytes in 0 msecs (HTTP/1.1 200) > 1 headers in 39 bytes (1 switches on core 0) > [pid: 4009|app: 0|req: 2/3] 127.0.0.1 () {32 vars in 427 bytes} [Sun Oct > 19 09:50:56 2014] POST / => generated 10 bytes in 0 msecs (HTTP/1.1 200) > 1 headers in 39 bytes (1 switches on core 0) > ______________________________ > > Note that there's nothing in the logs for the failed requests. > > When I run the server with wsgiref I get: > _______________________ >
Basically both wsgiref and uWSGI generates the same output (10 bytes). My suspect is that the java client is complaining about the fact the the output is not fully http/1.1 compliant. Can you try adding Connection: close header in the response ? Can you try removing the http proxy and using the http-socket option ? -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
