> Hello Roberto and fellow users. > > I'm using uWSGI in small to medium-sized production settings, behind > Nginx, without any HA (so no load balancing.) > > For small migrations and application updates I would like to (ideally) do > the following: > - have either Nginx or uWSGI put any incoming HTTP requests on hold > (accept them but not service them); > - have them complete any pending requests, currently being processed; > - manually perform backups, migrations, application updates and automated > tests; > - reload uWSGI with the new codebase; > - start servicing the requests that were put on hold. > > After perusing the list of signals supported by both Nginx and uWSGI, I > found uWSGI's SIGTSTP to be an excellent tool. > > I just send SIGTSTP to the uWSGI master process. Any requests received > after that are put on hold. I can update the codebase, perform migrations > and any required tests. After I'm done, I can touch-reload uWSGI, which > will then start servicing the frozen requests from the new codebase! > > This all works very well, which is a testament to the skill of uWSGI's > developer(s)!! > > If the upgrade steps I need to perform are automated and have already been > tested in a staging environment, I can do it all in a matter of seconds, > which is all the delay users are going to see. > > But I'm not clear about what happens to the requests that are being > processed at the time when I send the signal. > > Playing with some sleep()s and looking at uWSGI's log, it seems to me that > uWSGI does exactly what I describe above: puts any incoming requests on > hold, but keeps servicing current ones, until all workers are suspended. > > Is that really the case? Because I've had an instance where a worker was > still executing a query, which hung there during the migrations, causing > some trouble. (Maybe it was my fault, I wasn't checking the *** worker > suspended *** lines in the log at that time.) > > What are your thoughts? Is this feature intended to be used this way? Does > uWSGI always let existing requests complete, and does it always use the > new codebase to service the ones that were put on hold, if I unfreeze it > with a touch-reload? > > Thanks, > Tobia >
Yes, when you gracefully reload (or suspend) all the running requests are allowed to complete for a maximum of time (configurable) named the "mercy time". This works reliably in preforking mode and gevent mode. Multithreding mode works only on linux and solaris as on the other platforms thread cancellation is really flaky. You may be interested in zerg mode for a more advanced way (allowing rollbacks) -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
