Hi, Well....the workers always server requests. Think if is this way. I have a list that random servers pages test=[a,b,c] e.g. random.choice(test).
So...randomly, a page will be shown, either a,b,c for eash request. Then I update the list to just show two test=[a,b]. Only a and b should now be served. C should stopped being served. Yes..per the chart, there is what I call leakage. Somehow that page is still being served even though I removed C from the list. If I restart all servers.....problem solved but dont want to do that if I dont have to. On Sun, Dec 30, 2012 at 8:19 PM, Roberto De Ioris <[email protected]> wrote: > > > Hi, > > > > See the attached. Note the abrupt stop..thats where I updated the hash. > > I > > have 4 servers running one gevent loop per core. So..its clear that the > > code does what its supposed to do...but I guess there is a runaway > worker. > > I dont know how to explain it. > > > > If a whole worker lose the message you will not see such an abrupt stop > (each core in the worker would still be able to manage requests), so i > have to suppose a bunch (really few from the graph) of greenlets are still > up answering requests. > > How each greenlet knows it should stop answering requests ? Or better, > when a greenlet read that dictionary to stop itself ? > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
