I had a similar issue with ZeroMQ uWSGI and NGINX. What worked for me was turning off uwsgi_buffering and setting uwsgi_read_timeout to 300 on my nginx conf file.
On Fri, Apr 7, 2017 at 1:33 PM, Larry Martell <larry.mart...@gmail.com> wrote: > I have a django app that I serve with nginx and uwsgi. Some requests > that the app receives start python threads that are not complete when > the request returns a response to the client. When I run with the > django devel server the threads continue to run to completion. But > when I run with the djanbo prod server using nginx and uwsgi it seemed > that the threads terminate when the response is sent. But then I was > doing some more debugging and the server was in the state where it > seemed the threads were no longer running and then I restarted uwsgi > and then the threads ran to completion! So now I am very confused - > they clearly were still around, but seeming in some blocked state and > they were able to resume when uwsgi restarted. Can anyone shed any > light on what is going on? Is it feasible to run a thread that > continues after the request returns? > _______________________________________________ > uWSGI mailing list > uWSGI@lists.unbit.it > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
_______________________________________________ uWSGI mailing list uWSGI@lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
