> Hi, > > ok, some more tests later, I can still reproduce the problem :( To me it > *feels* like it happens less frequently, but it still happens. More > information about the setup: > > # uwsgi --version > 2.0.3 > > # /usr/bin/uwsgi --ini /etc/uwsgi/apps-enabled/myapp.ini > [uWSGI] getting INI configuration from /etc/uwsgi/apps-enabled/myapp.ini > *** Starting uWSGI 2.0.3 (64bit) on [Tue Apr 8 02:54:48 2014] *** > compiled with version: 4.6.3 on 08 April 2014 02:43:31 > os: Linux-3.2.0-60-generic #91-Ubuntu SMP Wed Feb 19 03:54:44 UTC 2014 > nodename: mynode > machine: x86_64 > clock source: unix > detected number of CPU cores: 8 > current working directory: /var/log > detected binary path: /usr/local/bin/uwsgi > !!! no internal routing support, rebuild with pcre support !!! > setgid() to 1010 > setuid() to 1002 > your processes number limit is 128020 > your memory page size is 4096 bytes > detected max file descriptor number: 1024 > lock engine: pthread robust mutexes > thunder lock: disabled (you can enable it with --thunder-lock) > uwsgi socket 0 bound to TCP address 127.0.0.1:4003 fd 3 > Python version: 2.7.3 (default, Feb 27 2014, 20:09:21) [GCC 4.6.3] > Python main interpreter initialized at 0xa4b480 > python threads support enabled > your server socket listen backlog is limited to 100 connections > your mercy for graceful operations on workers is 60 seconds > mapped 2503992 bytes (2445 KB) for 150 cores > *** Operational MODE: preforking+threaded *** > *** uWSGI is running in multiple interpreter mode *** > spawned uWSGI master process (pid: 16816) > spawned uWSGI worker 1 (pid: 16828, cores: 75) > spawned uWSGI worker 2 (pid: 16829, cores: 75) > WSGI app 0 (mountpoint='') ready in 2 seconds on interpreter 0xa4b480 pid: > 16829 (default app) > WSGI app 0 (mountpoint='') ready in 2 seconds on interpreter 0xa4b480 pid: > 16828 (default app) > > My config: > > [uwsgi] > master = 1 > workers = 2 > threads = 75 > max-requests = 100 > listen = 100 > socket = 127.0.0.1:4003 > file = /usr/bin/myapp.wsgi > callable = application > chdir = /var/lib/myapp/ > uid = myapp > gid = myapp_group > lazy = 1 >
Hi Clemens, i have re-read your previous post to understand your structure. There is something not clear: are the apps created at the first request, or from the WSGI entrypoint ? i mean, when create_app() is called ? The WSGI entry point is loaded before all of the threads are spawned, and so you should not have this problem. But if you start adding apps directly in a thread (during a request phase), the behaviour you get is expected (but you can easily fix it with locking) -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
