>> I think the easiest way would be having a persistent zergpool (it is an >> instance running to pass the socket to zergs) and simply suspend/resume >> the various instances. >> >> Zergpools are described at the end of the zerg page (zergpools instances >> can be managed by the emperor too) >> Roberto De Ioris > > > regular zergmode with a unix port is working well for me. I tried > setting up zergpools in my ini and they do not seem to work. I.e. if > I SIGTSTP the main uwsgi master then nothing happens, whereas with > regular zerg server and zerg master the zergs take all requests. This > is on Mac OsX with uWSGI 1.9.6 for development mode where we use http > = <port> instead of socket = <port>. in production we are behind > nginx and use socket mode. I see the pool created and zerg server > setup, but it never does any work. Am I set up/doing something wrong? > > thanks > > > uwsgi --ini uwsgi-development.ini > > uwsgi --zerg /tmp/zergpool_1 --ini uwsgi-development.ini:zerg > > [uwsgi] > env = PYRAMID_INI=development.ini > http = :6543 > master = true > processes = 4 > harakiri = 60 > harakiri-verbose = true > limit-post = 524288000 > post-buffering = 8192 > listen = 256 > #max-requests = 1000 > #reload-on-as = 128 > reload-on-rss = 96 > no-orphans = true > log-slow = true > enable-threads = true > virtualenv = ../env > wsgi-file = wsgi.py > #touch-chain-reload = ../Common/conf/restart > zergpool = /tmp/zergpool_1:127.0.0.1:6544,127.0.0.1:6545 > #zerg-server = /tmp/zergport > pidfile = /tmp/uwsgi_master.pid > > [zerg] > env = PYRAMID_INI=development.ini > #socket = :6544 > master = true > processes = 4 > harakiri = 60 > harakiri-verbose = true > limit-post = 524288000 > post-buffering = 8192 > listen = 256 > #max-requests = 1000 > #reload-on-as = 128 > reload-on-rss = 96 > no-orphans = true > log-slow = true > enable-threads = true > virtualenv = ../env > wsgi-file = wsgi.py > #zerg-fallback = true > pidfile = /tmp/uwsgi_zerg.pid > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
zergpools must be run separately from regular instances, you have a vassal for the zergpool, one for the first instance and one for the second. The zergpool vassal is never touched, the others constantly "dance" taking/leaving the socket -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
