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. -B On Wed, Apr 19, 2017 at 9:58 AM, Bryan Dina <bd...@dyn.com> wrote: > I am not aware of anything in my environment that would cause my > application reload, is this something that uWSGI does as part of its normal > lifecycle? I guess the question would be what causes reloads of an > application in uWSGI. I am controlling uWSGI using supervisord, so I'm > going to look through its configuration and documentation as well to figure > out whether that could be the cause of a reload/restart of uWSGI. > > Below is a link to my uWSGI configuration and for completeness, I also > included the supervisord configuration, > > https://gist.github.com/bdina/df6deeeb6abb95b1aad775b2b5c8d406 > > I will note that my configuration does have `autorestart=true` set. > > > -B > > On Wed, Apr 19, 2017 at 1:28 AM, Roberto De Ioris <robe...@unbit.it> > wrote: > >> >> > I'm recently having problems with a python flask application running on >> > uWSGI v2.0.12. This service is a REST API. What brought my attention to >> > uWSGI is when the API periodically would return 500 Internal Server >> error >> > responses for calls that should always return 200 success. Even requests >> > that happen on a frequent basis fail some of the time but not all of the >> > time. It does not seem to have anything to do with the request itself >> > (i.e. >> > the data in the request is correct). >> > >> > Digging through the logs I noticed that each time a 500 response would >> > happen, a log would be written with the text "no python application >> > found". >> > I then started looking for where this string would be coming from, and >> > found it in the uWSGI native code. >> > >> > At this point I am trying to understand what could be the origin of this >> > error. I notice that the string would only ever get logged when the >> > application id is found to be -1. What is not clear to me right now >> though >> > is what would cause that to happen? >> > >> > I can provide whatever information you need that I have not included in >> > this message in a reply. >> > >> > >> > >> >> Please post your configuration, but i would search better in uWSGI logs, >> it could happen if your workers are not able to correctly reload the >> application >> >> -- >> Roberto De Ioris >> http://unbit.com >> _______________________________________________ >> uWSGI mailing list >> uWSGI@lists.unbit.it >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >> > >
_______________________________________________ uWSGI mailing list uWSGI@lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
