Strugling with multiple workers setup

[pipozzz]

Hello,
I'd like to kindly ask about help with multiple workers setup.

I use gevent worker with gunicorn with -w 1 in from of this is nginx, and in front of this nginx I use aws ALB with stickysession enabled.

gunicorn --worker-class geventwebsocket.gunicorn.workers.GeventWebSocketWorker --max-requests 10000 --timeout 60 --keep-alive 60 --graceful-timeout 60 -w 1 -b 0.0.0.0:5000 --forwarded-allow-ips="*" run:app --enable-stdio-inheritance --access-logfile /proc/1/fd/1 --error-logfile /proc/1/fd/1 --daemon

flask-socketio I initialize like this:

socketio.init_app(app, debug=True, logger=True, cors_allowed_origins="*", engineio_logger=True,
message_queue=app.config['REDIS_URL'])

my nginx config

location / {
                proxy_pass http://127.0.0.1:5000;
                proxy_set_header Connection 'Upgrade';
                proxy_set_header Upgrade $http_upgrade;
                proxy_http_version 1.1;
                proxy_buffering off;
                proxy_cache off;
                proxy_redirect off;

                proxy_set_header   Host                 $host;
                proxy_set_header   X-Real-IP            $remote_addr;
                proxy_set_header   X-Forwarded-For      $proxy_add_x_forwarded_for;
                proxy_set_header   X-Forwarded-Proto    $http_x_forwarded_proto;
    }

When I have 1 worker it works fine, when I scale to 2 or so , then I'm getting 400 (Invalid session ID)

Do you have any idea where to look or what to adjust ?

Thanks for any help.

[miguelgrinberg]

The nginx configuration that you are showing here is for one worker, so I have no way to know what the problem is with multiple workers.

[pipozzz]

It seems that it's browser related issue, it's not working in Safari but works in Chrome, I'm debugging sticky sessions and it seems that Safari ignores cookie from AWS ALB (note: I'm connecting to different domain to API), but AWS ALB sets 2 cookies for that CORS situation but safari ignores it.

what do you think about disabling long-pooling so I could omit sticky sessions ?
Thanks for your help Miguel !

[miguelgrinberg]

The socket.io protocol gives the client the power to choose the initial transport, so you can change your clients to connect through websocket and avoid the sticky session requirement.

[pipozzz]

and does it have any disadvantage to omit long-pooling ?

[miguelgrinberg]

There are some, but are unrelated to Socket.IO. Browsers implement cross-origin protections for HTTP, but not for WebSocket (though this package does implement its own cross-origin protections in the server). The other one I can think of is that a WebSocket connection in the browser cannot carry custom headers, so auth via headers is not possible if you start with WS.

[pipozzz]

OK, thank for your help, it seems that I will do it with websocket transport only.