Difference between "message_queue" and "client_manager" parameters

[AdamAtFoyer]

I'm running several flask-socketio instances load balanced behind nginx. Once I added Celery to my app, I realized I needed to add "message_queue" for the tasks to communicate with my socketio instances. That works great (and I pass "message_queue" to the socketio constructor for both Celery and in the socketio instances).

But, after reviewing the documentation:

https://flask-socketio.readthedocs.io/en/latest/api.html

I'm seeing that there is also a "client_manager" parameter.

While trying to diagnose some transient issue, (my socketio servers are hanging after being online for a while) I'm starting to wonder if I have something misconfigured. Could you elaborate on what the "client_manager" option is for, and when we should use it?

Currently the docs say:

client_manager – The client manager instance that will manage the client list. When this is omitted, the client list is stored in an in-memory structure, so the use of multiple connected servers is not possible. In most cases, this argument does not need to be set explicitly.

It is not obvious to me the importance of the client list, and what issues might arise if this parameter is omitted in my multi-socketio instance setup. I see the docs say you don't need to set it explicitly, but I was wondering at what point do you have to pass something?

For example, I'm using sticky sessions for nginx, does this still mean I need to pass a client_manager?

Thanks! 💓

[miguelgrinberg]

The client_manager option is a lower-level version of message_queue that allows you to use custom queues. Other than that there is no difference, in fact, Flask-SocketIO looks at the scheme portion of the URL that you pass to message_queue to determine which client manager to use. For example, if your URL is redis://..., then a RedisManager is used.

[AdamAtFoyer]

Makes sense. Thanks so much for the incredible work you do Miguel. 🙏