> Hi all,
>
> We're facing a vexing issue with uwsgi where workers continue to handle
> requests, even if the app initialization fails. The bad worker doesn't
> exit, and will continue to process requests and return 500s to clients
> ("Python application not found"), even if the app's failure to initialize
> was due to a transient problem.
>
> We're using uwsgi 1.0.4 in emperor mode, with lazy worker loading.
>
> While researching, I came across bug 77 and this post which seems to be
> related:
> http://www.mail-archive.com/[email protected]/msg02767.html
>
> If this is the intended behavior of uwsgi, it seems to be highly
> problematic, and is unexpected. I would expect that an app that doesn't
> initialize properly would exit, or at least not continue to serve
> requests.This is the intended behaviour, as you can load app in uWSGI in every moment directly from the webserver or some external process speaking the uwsgi protocol. If i understand correctly you would like your instances to brutally fail if your app cannot be loaded. In lazy mode, that means worker respawning constantly. (Being controlled by the anti-fork-bombing policy). There is no problem in adding such an option, but it cannot be the default as loading multiple apps in uWSGI is a common practice, and users do not want a single app taking down all of the others ;) > > A quick review of the WSGI spec hasn't turned up anything that the app is > doing obviously wrong when exiting, but pointers would be appreciated. > (FWIW: the app is using Flask). WSGI specs (lucky enough) take care on only the gateway part. How the server handles failure is implementation specific. Thanks to this choice we can discuss about such a feature without asking on WEB-SIG :) -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
