> As part of this investigation yesterday I added some additional logging to > uWSGI (in plugins/python/python_plugin.c, plugins/python/pyloader.c, and > core/utils.c) to trace the execution flow in the app server, trying to > understand what it's doing when it tries to reload the application (which > is my REST API). > > On each request, uWSGI takes in the request and attempts to route it to > the > appropriate application handler in the uwsgi_request_wsgi function. This > function calls the uwsgi_get_app_id function to return the id to route the > request call to, but this call returns -1. That call returns -1 because an > application name is defined but there is an app count of 0. Back > in uwsgi_request_wsgi, it would next attempt to route to the default > application, but it too has a -1 id value. > > I see that when the "no python application found" log message is produced, > internally when the uWSGI code attempts to find the app id there are no > applications found - which makes sense. The next question though still to > answer is why would this be? I want to understand how uWSGI initializes > the > apps and further what events trigger said initialization. > > If there are other places or things I could do to instrument the code for > debugging with your advice I will go ahead and make those changes, build > the debug version of the uWSGI code and deploy. >
You could try adding the need-app = true option. This will ensure uWSGI will not start without a valid application loaded. This could end in your uWSGI logs filled with relevant data about the error. By the way, workers could get destroyed for various reasons (even the os could decide to kill a process), if a worker is not able to reload the app you wil get that error. Are you sure nothing about worker's death is in /var/local/dynect-email/mantle/logs/uwsgi/all.log ? -- Roberto De Ioris http://unbit.com _______________________________________________ uWSGI mailing list uWSGI@lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
