> Dnia poniedziałek, 13 lutego 2012 12:10:24 Roberto De Ioris pisze: >> > Dnia poniedziałek, 13 lutego 2012 11:56:15 Roberto De Ioris pisze: >> >> Regarding previous problem, can you paste the full config ? >> > >> > I use this config with 1.0: >> > >> > [uwsgi] >> > logger = syslog >> > threaded-logger = true >> > fastrouter = /var/run/uwsgi.socket >> > chmod-socket = 666 >> > fastrouter-subscription-server = :2626 >> > fastrouter-stats = :2580 >> > subscription-tolerance = 60 >> > master = true >> > listen = 1000 >> > fastrouter-events = 256 >> > >> > for 1.1 I've added "fastrouter-processes = 4" >> >> A problem: under multiple fastrouter processes who will be the stats server >> ? >> >> The bind error is triggered by processes trying to start the stats server. >> >> Maybe only the first fastrouter should manage them, otherwise we would need to put a heavy lock. > > Does it mean we would get stats only from one process?
Yes > write to > some shared area (with id x stats size offset or something if we want to avoids no shared area, locking in fastrouter like processes would be extremely overkill > locks)? Are stats/subscriptions are separate for each process? Maybe we should > put stats socket for every process? yes, when a subscription packet arrives on process X it will manages it and will re-route to the other processes. Looks like an hack, but it works and it is the fastest solutions. Having the stats server only on one fastrouter will mean losing datas of the others. I see no other solutions than having one port for each process :( -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
