On Fri, Apr 7, 2017 at 4:37 PM, Guillermo Cruz <webjunki...@gmail.com> wrote: > 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.
Thanks for the reply. We decided to redesign the app to use external processes instead of threads, but I will keep this email and I know it will come in handy in the future. > > 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
