> Hi, > > is there anything like --reload-mercy but for declaring maximum time > app startup is allowed to take? > I had an issue with one ruby app, it load gem at startup and this gem > connects to database that go overloaded, connection to that db hanged > and blocked app startup. > I think that uWSGI don't show any logs until app is loaded or failed > to load, but in this case it didn't showed anything making the issue > less easy to debug. > Startup time limit would help that since I would have information > where the issue is located. > I think that most helpful would be to have: > * uWSGI startup logging might be improved to dump current messages > after a while, even if we are still starting the app, I think that > right now messages are written to buffer and pushed using proper > logger plugin after app is fully loaded > * time limit for app startup, if app is taking longer to start then > kill it and start over, traceback of what app was doing would be great > and it should be easy since uWSGI already supports that > > Is any of the above possible right now? If not, can it be implemented? > >
Some ideas: 1.3 Emperor has the concept of heartbeat (pass heartbeat = <n> to vassals) Each vassal sends heartbeat at the specified frequency, if the emperor does not receive them the vassal is considered 'unloyal' and a reload message is sent. We can work on that area, implementing an emperor message for "printing" backtrace, when no heartbeat is sent in time. Having the instance monitor itself would require lazy mode (so the master can monitor it) or spawn a thread before each app loading (and stopping it as soon as the app is loaded). alarm() is pretty useless as lot of apps use it (cancelling the uWSGI-one) Backtrace is implemented only for python apps, so (as an example) ruby apps would only get c backtrace. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
