> On Thu, Feb 23, 2012 at 2:33 PM, Roberto De Ioris <[email protected]> > wrote: > >> >> 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 ;) >> > > Can you clarify what difference lazy mode makes here? If there's a > workaround that involves not using lazy mode, we'd consider it. (Lazy mode > is being used to avoid sharing memcache and DB connections among workers > vs > implementing the post_fork_hook.)
In non lazy-mode, the app is loaded by the master. If it fails (having enabled your requested behaviour), the whole stack exits (without spawning workers) and the emperor will requeue-it (and the emperor is smarter than the master in avoiding fork bombing). In lazy mode, the master starts the workers before loading the apps, so if the app loading fails and you do not want the default behavior, your worker will start respawning constantly (the master has a simple anti-fork-bomb policy). If you have lot of workers this could be a waste of cpu resources. There are plugins (like the ruby one) triggering an exit if an app cannot be loaded (as ruby does not support multiple apps in the same process), so adding such a features is a matter of 2-3 lines of code. The only problem is how to manage the lazy workers. Is having a controlled-by-the-user rate-limiter for fork enough ? Just to clarify: 1) master starts 2) 4 workers starts 3) app load successfully, goto 6 4) worker exit (app cannot be loaded) 5) goto 2 6) start accepting requests We need to avoid bombing in points 2-4 -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
