Hi Roberto, Hi, the http: routing rule must be managed by workers, so you have: > > https -> balancer-workers -> gevent websockets > > i would enable gevent even for the balancer-workers too, otherwise with a > single worker you will not get any kind of concurrency >
I understand that the configuration I posted for the router is actually equivalent to --master --workers=1: if there are a lot of ws connections, this is going to be a problem since only one connection will be handled by the single default worker. The others will not be accepted. I was under the impression that --gevent only enabled async support for a python-based app managed by uwsgi but after reading the documentation (and the code) more carefully, I believe that --gevent actually changes the way uwsgi core handles incoming requests. i.e., uwsgi core actually uses the python runtime gevent implementation to perform its core switching. Right ? So, I have a couple of options for my router: 1. --master --workers=many --threads=many --gevent=many 2. --master --workers=many --threads=1 --gevent=many 3. --master --workers=1 --threads=1 --gevent=many Do you have a specific suggestion about the one I should use ? Now, your comment helped me better understand my configuration but I do not think it answered my original question: > Sadly, I have not yet figured out why the uwsgi proxy is trying to so hard > > to close my ws connections. > > > > Any idea on how I might try to debug this further or suggestions on how I > > could tweak the configuration of my uwsgi proxy ? > i.e., I can confirm than adding --gevent=many to my router configuration does not change anything to this problem: the uwsgi router appears to be still disconnecting the client from the ws app after a while. Any other suggestion ? Mathieu
_______________________________________________ uWSGI mailing list uWSGI@lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
